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REMARKS 

Initially, Applicants would like to thank the Examiner and her supervisor for their 
courtesy shown in the personal interview with Applicants' representative, Joshua M. 
Povsner, on September 14, 2004. Applicants would also like to thank the Examiner for 
her courtesy in preparing and forwarding a mutually-acceptable (supplemental) Interview 
Summary following the above-noted personal interview. 

In the above-noted Final Official Action, the Examiner rejected claims 8-18 under 
35 U.S.C. 103(a) over MICALI (U.S. Patent No. 5,666,420) in view of ANGEBAUD et 
al. (U.S. Patent No. 5,218,637). 

During the above-noted personal interview, Applicants representative discussed 
the rejection, and particularly the MICALI reference. As noted in the Interview 
Summary, the Examiner maintained that MICALI discloses mutual authentication through 
verification of a digital signature before the exchange of unencrypted digital data. Upon 
the conclusion of the interview, Applicants' representative agreed to consider the 
Examiner's interpretation and to either amend the claims or to traverse the rejection 
without amendment in a response. 

Upon further review of the references applied in the outstanding Final Official 
Action, Applicants are submitting the present response, as well as the supplemental 
Exhibits, so as to traverse the rejection without amendment. In this regard, Applicants 
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respectfully submit that the rejection of claims 8-18 under 35 U.S.C. § 103(a) is improper, 
and respectfully request reconsideration and withdrawal thereof in view of the herein- 
contained remarks. 
MICALI 

Initially, Applicants would like to summarize the teachings of MICALI, before 
explaining the differences between the broadest reasonable interpretation of MICALI and 
the features recited in claim 8. In this regard, in the embodiment disclosed in Figure 5 of 
MICALI (i.e., the embodiment relied on in the Final Official Action, discussed during the 
above-noted Interview and noted in the Interview Summary), an electronic transaction 
protocol allows two parties (A and B) to perform simultaneous transactions with 
minimum help from a trusted third party. 

In step Al, the protocol requires a first party (A) to compute an encryption (z) in 
the third party's (Post Office's) public key of a triplet, i.e., z=E PO ((A, B, E B (m))). The 
triplet consists of identifiers (A) for the first party, (B) for the second party, and (E B (m)) 
for the message (m) encrypted in the second party's (B's) key. The message (m) from A 
to B is generally analogous to the first digital data of the present invention, and the 
encryption in the Post Office's public key of the message, i.e. (z), is generally analogous 
to the encrypted first digital data of the present invention (as "z" is sent from the first 
party (A) to the second party (B) in step Al). 
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In step Bl , the second party (B) digitally signs the received encrypted message (z) 
and sends it to the first party (A) as a receipt. 

In step A2 5 if the first party (A) receives the properly signed receipt from the 
second party (B), the first party sends the second party (B) an encryption of the message 
(m) that is encrypted in a way understandable by (B) alone (i.e., E B (m), which is the 
message (m) encrypted only in (B)'s key, i.e., but not in the Post Office's key E P0 . 

In step B2, the second party (B) receives E B (m) and verifies that the encrypted 
message (E B (m)) corresponds to the message previously received (z=E po (A, B 5 E B (m))), 
e.g., using the Post Office's key E P0 to ensure that the encryption of A, B and E B (m) 
corresponds to that which was received in step Al . If the second party (B) verifies that 
the encrypted message (E B (m)) corresponds to the message previously received (z=E po (A, 
B, E B (m))), the second party (B) is satisfied. However, if the second party (B) does not 
receive E B (m), the second party (B) signs the message previously received (z=E p0 (A, B, 
E B (m))) in step Al and sends the signed message to the Post Office along with 
information to indicate that the message was sent from the first party (A) and received by 
the second party (B). 
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In step P0 5 if the second party's digital signature is correct, the Post Office 
decrypts E po (A, B, E B (m)) to obtain A, B and E B (m), verifies that A, B and E B (m) are 
obtained, and sends the first party (A) the value "z", i.e., E po (A, B, E B (m)), signed by the 
second party (B), and sends E B (m) to the second party (B). 

In the above-noted personal interview, and as indicated in the Interview Summary 
mailed on September 30, 2004, the Examiner asserted that the Summary of the Invention 
and Column 5, line 1 to Column 6, line 17 in MICALI disclose the features related to an 
authentication certificate as recited in the claims. In this regard, claim 8 recites: 

"the first party encrypting the first digital data and generating an authentication 
certificate, the authentication certificate authenticating that the encrypted first digital data 
is an encryption of the first digital data , and sending the encrypted first digital data and 
the authentication certificate to the second party; 

the second party verifying that the encrypted first digital data is an encryption of 
the first digital data using the authentication certificate , and the second party sending the 
second digital data to the first party when the encrypted first digital data is an encryption 
of the first digital data" (emphasis added). 

Initially, Applicants note that the outstanding Final Official Action is premised on 
interpreting MICALI such that the claimed first party is "Alice" (A), the claimed second 
party is "Bob" (B), and the claimed third party is the "Post Office" (PO). With respect to 
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the outstanding Final Official Action, Interview and Interview Summary, Applicants 
respectfully submit that MICALI does not disclose at least the "first party... generating an 
authentication certificate, the authentication certificate authenticating that the encrypted 
first digital data is an encryption of the first digital data, and sending the encrypted first 
digital data and the authentication certificate to the second party". In this regard, there is 
no disclosure of an "authentication certificate" in MICALI anywhere, let alone at column 
5, line 1 to column 6, line 17. In particular, MICALI does not use the term 
"authentication" or "certificate" at column 5, line 1 to column 6, line 17, and does not use 
the term "certificate" or an equivalent term whatsoever. 

Rather, MICALI discloses, at column 5, lines 1-3, that "[u]sers and the Post Office 
can digitally sign messages" using a "secret signing key and a matching public 
verification key" (emphasis added). Additionally, MICALI discloses, at column 5, lines 
9-14, that "[u]sers... can encrypt messages by means of a public-key encryption 
algorithm" using "a public encryption key and a corresponding secret decryption key". 
An encryption "y" of a message "m" can be checked using a public key (such as that of 
Bob and/or the Post Office as appropriate) to see if the encryption of "m" is equal to "y". 

MICALI also discloses, at column 6, lines 1-13, that "Alice sends z to Bob 
digitally signed by her" (emphasis added). Further, MICALI discloses, at column 6, lines 
4-9, that "when Alice holds a receipt for m signed by Bob, he will have a certified version 
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of m" and "if z is digitally signed by Alice, Bob first checks Alice's signature , and then 
countersigns z himself (emphasis added). Finally, MICALI discloses, at column 6, lines 
14-17, that "[i]n analyzing the protocol, it should be noted that Alice, given Bob's 
signature of z as receipt, can prove the content of the message" (emphasis added). 
Accordingly, MICALI only discloses the use of digital signatures and encryption, but not 
the use of digital certificates, let alone the features recited in claim 8 that relate to digital 
certificates. 

Accordingly, based on the outstanding Final Official Action, the Interview and the 
Interview Summary, it appears that the Examiner is asserting that a digital signature 
necessarily invokes or accompanies an authentication certificate. Applicants respectfully 
assert that such a position is incorrect, and that a digital signature is not the same as and 
does not necessarily invoke an authentication certificate or the features recited in claim 8 
that relate to an authentication certificate. Further, Applicants respectfully assert that the 
digital signature of MICALI is not the same as, and does not necessarily invoke or 
accompany, the authentication certificate or the features recited in claim 8 that relate to an 
authentication certificate. 

Applicants refer the Examiner to a document downloaded from a website of the 
U.S. Computer Emergency Readiness Team at <www.us-cert.gov/cas/tips/ST04- 
018.html>, attached hereto as "Exhibit A". /The above noted website defines a digital 
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signature as a way to verify that an email message is from the person who purportedly 
sends the email message, as well as that the contents of the message haven't changed. A 
similar definition is also found in, e.g., the Abstract and page 7 of the document "Digital 
Signature Standard" provided by the U.S. Department of Commerce/National Institute of 
Standards and Technology, "attached hereto as Exhibit C". ^ 

Additionally, an explanation of how a digital signature is normally applied to a 
message is found at <www.xml.com/pub/a/2001/08/08.xmldsig.html>, attached hereto as 
"Exhibit B". In the fourth paragraph under the section "An introduction to Public Key 
Cryptography" of Exhibit B, it is explained that to "create a digital signature for a 
message, the data to be signed is transformed by an algorithm that takes as input the 
private key of the sender. Because a transformation takes as a parameter the sender's 
public key, a recipient of the transformed data can be confident of the origin of the data 
(the identity of the sender). If the data can be verified using the sender's public key, then 
it must have been signed using the corresponding private key (to which only the sender 
should have access)". 

In the subsequent paragraph of Exhibit B (i.e., in the fifth paragraph under the 
section "An introduction to Public Key Cryptography"), Exhibit B provides the difference 
between a digital signature and an authentication certificate, and explains that an 
authentication certificate (issued by a Certification Authority) "is an assertion of the 
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validity of the binding between the certificate's subject (the owner of the cryptographic 
keys) and her public key such that other users can be confident that the public key does 
indeed correspond to the subject who claims it as her own" (emphasis added). In view of 
the above noted differences in the explanations of a digital signature and an 
authentication certificate, Applicants submit that the digital signatures of MICALI is not 
an authentication certificate. 

Furthermore, Applicants submit that, although no authentication certificate is 
disclosed in MICALI, any authentication certificate associated with the issuance of 
private/public keys could be provided and retained at a Certification Authority. Using a 
Certification Authority, a recipient of a signed message could check the authenticity of 
the sender's public key. Thus, the digital signature of MICALI does not inherently 
disclose or invoke (i.e., require) an authentication certificate that is transmitted together 
with the digital signature from a first party to a second party as recited in claim 8 as, if an 
authentication certificate is required, it could be provided and retained at a Certification 
Authority and made available upon request of a recipient. Accordingly, Applicants 
respectfully submit that MICALI does not disclose, either explicitly or inherently, at least 
the "first party... sending the encrypted first digital data and the authentication certificate 
to the second party" or "the second party verifying that the encrypted first digital data is 
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an encryption of the first digital data using the authentication certificate", as recited in 
claim 8. 

Applicants also submit that the digital signature in MICALI cannot obtain the 
same benefits as those provided by the authentication certificate in claim 8. In this 
regard, the present invention relates to a method of exchanging digital data between a first 
party having a unique first digital data and a second party having a unique second digital 
data. The first digital data is encrypted by the first party and sent to the second party 
together with an authentication certificate authenticating the encryption performed so that 
the second party can make use of the authentication certificate to ascertain the 
authenticity of the encryption of the first digital data (as the second party cannot obtain 
the first digital data directly). 

In contrast, MICALI discloses, in the Summary of the Invention and at column 4, 
lines 1-2, that the first party's value is a message and the second party's value is a receipt. 
Thus, in accordance with the above-noted description at column 5 of steps Al and Bl, 
the first party's value is the message "m" from Alice and the second party's value (i.e., 
the receipt) is the signature of z by Bob at step Bl. 

In MICALI the message "m" is encrypted using Bob's public key to generate 
E B (m), but E B (m) cannot be the encryption of the first digital data of the present invention 
since this is encrypted with Bob's public key (which Bob can decrypt easily). Thus, the 
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encryption of the first digital data in MICALI would be "z", which is E po (A, B, E B (m)) 
because Bob does not have the private key of the Post Office and has no way of obtaining 
E B (m) within z (i.e., within E po (A, B, E B (m)). However, "z" is not an authentication 
certificate since "z" does not provide any authentication information to Bob (since "z" is 
encrypted using the public key of the Post Office). Further, as noted for step Bl at 
column 5, lines 50-51, no verification is performed by Bob using "z". 

MICALI discloses, at column 6, lines 1-5, that Alice can use her secret key to sign 
"z". Referring to column 5, lines 3-5, the digital signature by Alice on "z" would be 
SIG A (z) = SIG A (E po (A, B, E B (m)). It is this digitally signature on "z" which was 
referenced in the above-noted interview, and which is the subject of column 6 referenced 
in the above-noted Interview Summary. In particular, the Examiner's interpretation 
appears to be that this digital signature on "z" is an authentication certificate. However, 
SIG A (z) is not a digital certificate. Rather, SIG A (z) merely conveys that if Bob uses 
Alice's public key to decrypt SIG A (z) and determines that Alice is the sender (as noted in 
MICALI at column 6, lines 1-7), then Bob verifies that Alice is the sender. Thus, Alice's 
signature of "z" merely allows Bob to verify the origin of the message and that it has not 
been modified after Alice signed "z" (as any modification would alter "z" to, e.g., be 
undecryptable/unintelligible upon decryption). However, Alice's signature of "z" would 
not give any assurance to Bob that "z" is necessarily an encryption of the first digital data 
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"m" (the first digital data). Rather, Alice's signature of "z" would only verify Alice as 
the source and that the contents of "z" were not modified after signing. In contrast, the 
authentication certificate of the present invention authenticates that the encrypted first 
digital data is an encryption of the first digital data . Thus, the digital signature of 
MICALI can not obtain the same result for Bob as the authentication certificate recited in 
claim 8 obtains for the second party. 

Applicants further submit that the protocol taught by MICALI does not invoke an 
authentication certificate as is recited in claim 8. In this regard, MICALI teaches only 
digital signatures. However, even if an authentication certificate were provided in 
MICALI, MICALI discloses at column 5, lines 13-14 that E A (m), E B (m) and E P0 (m) are 
encryptions of a message "m" with the respective public keys of Alice, Bob and the Post 
Office. Further, as explained above, with steps Al and Bl in MICALI, Bob cannot verify 
the authenticity of "z" or the authenticity of the sender, since M z" is signed using the 
public key of the Post Office and Bob does not have the corresponding private/secret key 
of the Post Office (see also column 6, lines 34-39 and column 4, lines 15-18). Thus, Bob 
does not verify the message M z" in Bl, let alone authenticate the message using an 
authentication certificate. 

MICALI also discloses, at column 6, line 1, that Alice digitally signs "z" and sends 
it to Bob so that Bob can be certain that "z" comes from Alice (see also column 6, lines 4- 
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5). However, this "mutual authentication' 1 (the term used by the Examiner in the 
Interview Summary) only involves using cryptography as described above, for Alice to 
sign "z" using her private key and for Bob to use Alice's public key to verify that "z" is 
from Alice. 

Accordingly, MICALI does not disclose or suggest that sending "z" to Bob also 
invokes sending an authentication certificate to Bob. As previously explained, an 
authentication certificate for private/public keys can be provided at a Certification 
Authority, and does not require that such an authentication certificate be provided with 
"z". Further, as previously explained, MICALI does not disclose or suggest that an 
authentication certificate is provided with "z", particularly because MICALI does not 
even mention the term "certificate", let alone an "authentication certificate", anywhere in 
the disclosure thereof. 

Accordingly, even if an authentication certificate were used in MICALI (which 
MICALI does not disclose), any such authentication certificate would serve as a 
verification document, for Bob to verify that "z" is sent from Alice. However, this 
verification would merely serve to assure Bob of the identity of the party sending "z" and 
whether its contents have been modified since the signing of "z" using Alice's private key 
(see column 6, lines 4-5 of MICALI). Even such a use of an authentication certificate, 
which is not disclosed in MICALI, would be different from the features related to the 
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authentication certificate as recited in claim 8 (i.e., an authentication certificate that is 
sent to the second party and that authenticates that the encrypted first digital data is an 
encryption of the first digital data). 

Accordingly, Applicants respectfully submit that MICALI does not disclose, 
suggest or otherwise teach the above-noted features recited in claim 8. Applicants further 
submit that MICALI does not obtain the benefits provided by the invention recited in 
claim 8. In particular, MICALI does not provide any teaching of an "authentication 
certificate" as in the present invention, let alone an "authentication certificate 
authenticating that the encrypted first digital data is an encryption of the first digital data", 
as is recited in claim 8. Furthermore, MICALI does not disclose any feature similar to 
"the first party... sending the encrypted first digital data and the authentication certificate 
to the second party", as is recited in claim 8. Moreover, MICALI does not disclose any 
feature similar to "the second party verifying that the encrypted first digital data is an 
encryption of the first digital data using the authentication certificate", as is recited in 
claim 8. 

Applicants further submit that the above-noted features are not disclosed or 
suggested by ANGEBAUD; nor has the Examiner asserted in the above-noted Final 
Official Action, in the Personal Interview, or in the Interview Summary, that the above- 
noted features are disclosed or suggested by ANGEBAUD. Accordingly, because the 
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combination of references applied by the Examiner do not disclose each and every one of 
the features recited in claim 8, Applicants respectfully submit that the rejection of claim 8 
is inappropriate. 

Accordingly, at least for each and all of the reasons noted above, Applicants 
respectfully submit that claim 8 is allowable over the references applied in the 
outstanding Official Action. Applicants additionally submit that each of claims 9-18 are 
allowable, at least for depending from an allowable independent claim 8, as well as for 
additional reasons related to their own recitations. 

Accordingly, Applicants respectfully request reconsideration and withdrawal of 
each of the outstanding rejections, as well as an indication of the allowability of each of 
the claims now pending. 
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ciT M pARV ANP rnNn.TISlON 
Applicants have made a sincere effort to place the present application in condition 
for allowance, and believe that they have now done so. Applicants have discussed the 
features recited in Applicants' claims, and have shown how the combination of features 
recited in Applicants' claims are not taught, disclosed nor rendered obvious by the 
references cited by the Examiner. Accordingly, reconsideration and withdrawal of the 
outstanding rejections, as well as an indication of the allowance of each of the pending 

claims, is respectfully requested. 

Should the Examiner have any questions, the Examiner is invited to contact the 

undersigned at the below-listed telephone number. 



November 4, 2004 

GREENBLUM & BERNSTEIN, P.L.C. 
1950 Roland Clarke Place 
Reston, VA 20191 
(703)716-1191 



Respectfully submitted, 
Feng/BAQ et al. 




Bruce H. Bet 
Reg. No. 29,027 
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Understanding Digital Signatures 



Digital signatures are a way to verify that an email message is really from the 
person who supposedly sent it and that it hasn ! t been changed. 



What is a digital signature? 

You may have received emails that have a block of letters and numbers at the bottom of the 
message. Although it may look like useless text or some kind of error, this information is actually a 
digital signature. To generate a signature, a mathematical algorithm is used to combine the 
information in a key with the information in the message. The result is a random-looking string of 
letters and numbers. 

Why would you use one? 

Because it is so easy for attackers and viruses to "spoof email addresses (see Using Caution with 
Email Attachments for more information), it is sometimes difficult to identify legitimate messages. 
Authenticity may be especially important for business correspondence— if you are relying on 
someone to provide or verify information, you want to be sure that the information is coming from 
the correct source. A signed message also indicates that changes have not been made to the 
content since it was sent; any changes would cause the signature to break. 

How does it work? 

Before you can understand how a digital signature works, there are some terms you should know: 

• Keys - Keys are used to create digital signatures. For every signature, there is a public key 
and a private key. 

o Private key - The private key is the portion of the key you use to actually sign an 
email message. The private key is protected by a password, and you should never 
give your private key to anyone. 

o Public key - The public key is the portion of the key that is available to other people. 
Whether you upload it to a public key ring or send it to someone, this is the key other 
people can use to check your signature. A list of other people who have signed your 
key is also included with your public key. You will only be able to see their identify if 
you already have their public keys on your key ring. 

• Key ring - A key ring contains public keys. You have a key ring that contains the keys of 
people who have sent you their keys or whose keys you have gotten from a public key 
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server. A public key server contains keys of people who have chosen to upload their keys. 

• Fingerprint - When confirming a key, you will actually be confirming the unique series of 
letters and numbers that comprise the fingerprint of the key. The fingerprint is a different 
series of letters and numbers than the chunk of information that appears at the bottom of a 
signed email message. 

• Key certificates - When you select a key on a key ring, you will usually see the key 
certificate, which contains information about the key, such as the key owner, the date the 
key was created, and the date the key will expire. 

• "Web of trust" - When someone signs your key, they are confirming that the key actually 
belongs to you. The more signatures you collect, the stronger your key becomes. If 
someone sees that your key has been signed by other people that he or she trusts, he or 
she is more inclined to trust your key. Note: Just because someone else has trusted a key 
or you find it on a public key ring does not mean you should automatically trust it. You 
should always verify the fingerprint yourself. 

The process for creating, obtaining, and using keys is fairly straightforward: 

1. Generate a key using software such as PGP, which stands for Pretty Good Privacy, or 
GnuPG, which stands for GNU Privacy Guard. 

2. Increase the authenticity of your key by having your key signed by co-workers or other 
associates who also have keys. In the process of signing your key, they will confirm that the 
fingerprint on the key you sent them belongs to you. By doing this, they verify your identity 
and indicate trust in your key. 

3. Upload your signed key to a public key ring so that if someone gets a message with your 
signature, they can verify the digital signature. 

4. Digitally sign your outgoing email messages. Most email clients have a feature to easily add 
your digital signature to your message. 
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CATEGORY: COMPUTER SECURITY 



U.S. DEPARTMENT OF COMMERCE, William M. Daley, Secretary 
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY, 
Raymond G. Kammer, Director 



Foreword 



The Federal Information Processing Standards Publication Series of the National Institute of 
Standards and Technology (NIST) is the official series of publications relating to standards and 
guidelines adopted and promulgated under the provisions of Section 5131 of the Information 
Technology Management Reform Act of 1996 (Public Law 104-106), and the Computer Security 
Act of 1987 (Public Law 100-235). These mandates have given the Secretary of Commerce and 
NIST important responsibilities for improving the utilization and management of computer and 
related telecommunications systems in the Federal Government. The NIST, through its Information 
Technology Laboratory, provides leadership, technical guidance, and coordination of Government 
efforts in the development of standards and guidelines in these areas. 

Comments concerning Federal Information Processing Standards Publications are welcomed and 
should be addressed to the Director, Information Technology Laboratory, National Institute of 
Standards and Technology, 100 Bureau Dr.. Stop 8900, Gaithersburg, MD 20899-8900. 

William Mehuron, Director 
Information Technology Laboratory 



Abstract 

This standard specifies a suite of algorithms which can be used to generate a digital signature. 
Digital signatures are used to detect unauthorized modifications to data and to authenticate the 
identity of the signatory. In addition, the recipient of signed data can use a digital signature in 
proving to a third party that the signature was in fact generated by the signatory. This is known as 
nonrepudiation since the signatory cannot, at a later time, repudiate the signature. 

Key words: ADP security, computer security, digital signatures, public-key cryptography, Federal 
Information Processing Standards, 
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Federal Information 
Processing Standards Publication 186-2 

2000 January 27 

Announcing the 

DIGITAL SIGNATURE STANDARD (DSS) 



Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National 
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant 
to Section 513 1 of the Information Technology Management Reform Act of 1996 (Public Law 104- 
106), and the Computer Security Act of 1987 (Public Law 100-235). 

Name of Standard: Digital Signature Standard (DSS). 

Category of Standard: Computer Security, Cryptography. 

Explanation: This Standard specifies algorithms appropriate for applications requiring a digital, 
rather than written, signature. A digital signature is represented in a computer as a string of binary 
digits. A digital signature is computed using a set of rules and a set of parameters such that the 
identity of the signatory and integrity of the data can be verified. An algorithm provides the 
capability to generate and verify signatures. Signature generation makes use of a private key to 
generate a digital signature. Signature verification makes use of a public key which corresponds to, 
but is not the same as, the private key. Each user possesses a private and public key pair. Public 
keys are assumed to be known to the public in general. Private keys are never shared. Anyone can 
verify the signature of a user by employing that user's public key. Signature generation can be 
performed only by the possessor of the user's private key. 

A hash function is used in the signature generation process to obtain a condensed version of data, 
called a message digest (see Figure 1). The message digest is then-input to the digital signature (ds) 
algorithm to generate the digital signature. The digital signature is sent to the intended verifier along 
with the signed data (often called the message). The verifier of the message and signature verifies 
the signature by using the sender's public key. The same hash function must also be used in the 
verification process. The hash function is specified in a separate standard, the Secure Hash Standard 
(SHS), FIPS 180-1. FIPS approved ds algorithms must be implemented with the SHS. Similar 
procedures may be used to generate and verify signatures for stored as well as transmitted data. 
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Approving Authority: Secretary of Commerce. 

Maintenance Agency: U.S. Department of Commerce, National Institute of Standards and 
Technology (NIST), Information Technology Laboratory (ITL). 

Applicability: This standard is applicable to all Federal departments and agencies for the protection 
of sensitive unclassified information that is not subject to section 2315 of Title 10, United States 
Code, or section 3502(2) of Title 44, United States Code. This standard shall be used in designing 
and implementing public-key based signature systems that Federal departments and agencies operate 
or which are operated for them under contract. Adoption and use of this standard is available to 
private and commercial organizations. 

Applications: A digital signature (ds) algorithm authenticates the integrity of the signed data and 
the identity of the signatory. A ds algorithm may also be used in proving to a third party that data 
was actually signed by the generator of the signature. A ds algorithm is intended for use in electronic 
mail, electronic funds transfer, electronic data interchange, software distribution, data storage, and 
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other applications that require data integrity assurance and data origin authentication. The 
techniques specified in ANSI X9.31 and ANSI X9.62 may be used in addition to the Digital 
Signature Algorithm (DSA) specified herein. (NISI editorial note: either DSA, RSA [ANSI X9.3 1], 
or ECDSA [ANSI X9.62] may be used; all three do not have to be implemented.) 

Implementations: A ds algorithm may be implemented in software firmware, hardware or any 
combination thereof. NIST has developed a validation program to test implementations for 
conformance to DSA. Currently, conformance tests for ANSI X9.31 and ANSI X9.62 have not been 
developed. These tests will be developed and made available in the future. Information about the 
planned validation program can be obtained from the National Institute of Standards and 
Technology, Information Technology Laboratory, Attn: DSS Validation, 100 Bureau Drive Stop 
8930, Gaithersburg, MD 20899-8930. 

Agencies are advised that separate keys should be used for signature and confidentiality purposes 
when using the X9.31 standard. This is because the RSA algorithm can be used for both data 
encryption and digital signature purposes. 

Export Control: Certain cryptographic devices and technical data regarding them are subject to 
Federal export controls. Applicable Federal government export controls are specified in Title 15, 
Code of Federal Regulations (CFR) Part 740.17; Title 15, CFR Part 742; and Title 15, CFR Part 774, 
Category 5, Part 2. 

Patents: The algorithms in this standard may be covered by U.S. or foreign patents. 

Implementation Schedule: This standard becomes effective July 27, 2000. A transition period from 
July 27, 2000 until July 27, 2001 is provided to enable all agencies to develop plans for the 
acquisition of equipment which implements the digital signature techniques adopted by FIPS 186-2. 
During the transition period, agencies may continue to use their existing digital signature systems 
and to acquire additional equipment that may be needed to interoperate with these legacy digital 
signature systems. Agencies without legacy digital signature systems should plan for the acquisition 
and use of equipment implementing the digital signature techniques that are adopted by FIPS 186-2. 
After the transition period, only equipment that implements FIPS 186-2 endorsed techniques should 
be acquired. 

Specifications: Federal Information Processing Standard (FIPS) 186-2 Digital Signature Standard 
(affixed). Also see an important change notice at the end of this document. 

Cross Index: 

a. FIPS PUB 46-3, Data Encryption Standard. 

b. FIPS PUB 73, Guidelines for Security of Computer Applications. 
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c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. 

d. FIPS PUB 1 7 1 , Key Management Using ANSI X9. 1 7. 

e. FIPS PUB 180-1, Secure Hash Standard. 

f. ANSI X9.3 1-1998, Digital Signatures Using Reversible Public Key Cryptography for the 
Financial Services Industry (rDSA). 

g. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic 
Curve Digital Signature Algorithm (ECDSA). 

Qualifications: The security of a digital signature system is dependent on maintaining the secrecy 
of users' private keys. Users must therefore guard against the unauthorized acquisition of their 
private keys. While it is the intent of this standard to specify general security requirements for 
generating digital signatures, conformance to this standard does not assure that a particular 
implementation is secure. The responsible authority in each agency or department shall assure that 
an overall implementation provides an acceptable level of security. This standard will be reviewed 
every five years in order to assess its adequacy. 

Waiver Procedure: Under certain exceptional circumstances, the heads of Federal agencies, or their 
delegates, may approve waivers to Federal Information Processing Standards (FIPS). The head of 
such agency may redelegate such authority only to a senior official designated pursuant to section 
3506(b) of Title 44, United States Code. Waiver shall be granted only when: 

a. Compliance with a standard would adversely affect the accomplishment of the mission of an 
operator of a Federal computer system; or 

b. Cause a major adverse financial impact on the operator which is not offset by Government wide 
savings. 

Agency heads may act upon a written waiver request containing the information detailed above. 
Agency heads may also act without a written waiver request when they determine that conditions for 
meeting the standard cannot be met Agency heads may approve waivers only by a written decision 
which explains the basis on which the agency head made the required finding(s). A copy of each 
such decision, with procurement sensitive or classified portions clearly identified, shall be sent to: 
National Institute of Standards and Technology; ATTN: FIPS Waiver Decisions, 100 Bureau Drive 
Stop 8970, Gaithersburg, MD 20899-8970. 

In addition, notice of each waiver granted and each delegation of authority to approve waivers shall 
be sent promptly to the Committee on Government Operations of the House of Representatives and 
the Committee on Governmental Affairs of the Senate and shall be published promptly in the Federal 
Register. 
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When the determination on a waiver applies to the procurement of equipment and/or services, a 
notice of the waiver determination must be published in the Commerce Business Daily as a part of 
the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that 
notice is published, by amendment to such notice. 

A copy of the waiver, any supporting documents, the document approving the waiver and any 
supporting and accompanying documents, with such deletions as the agency is authorized and 
decides to make under 5 U.S.C. Sec. 552(b), shall be part of the procurement documentation and 
retained by the agency. 

Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National 
Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When 
ordering, refer to Federal Information Processing Standards Publication 186-2 (FIPSPUB 1 86-2), and 
identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS 
in current catalogs and other issuances. Payment may be made by check, money order, deposit 
account or charged to a credit card accepted by NTIS. 
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Specifications for the 



DIGITAL SIGNATURE STANDARD (DSS) 



1. INTRODUCTION 

This publication prescribes three algorithms suitable for digital signature (ds) generation and 
verification. The first algorithm, the Digital Signature Algorithm (DSA), is described in sections 
4 - 6 and appendices 1 - 5. The second algorithm, the RSA ds algorithm, is discussed in section 7 
and the third algorithm, the ECDSA algorithm, is discussed in section 8 and recommended elliptic 
curves in appendix 6. An important change notice has been appended to this document. 



2. GENERAL 

When a message is received, the recipient may desire to verify.that the message has not been altered 
in transit. Furthermore, the recipient may wish to be certain of the originator's identity. Both of 
these services can be provided by a ds algorithm. A digital signature is an electronic analogue of a 
written signature in that the digital signature can be used in proving to the recipient or a third party 
that the message was, in fact, signed by the originator. Digital signatures may also be generated for 
stored data and programs so that the integrity of the data and programs may be verified at any later 
time. 

This publication prescribes two algorithms suitable for digital signature generation and verification. 



3, USE OF A DIGITAL SIGNATURE (ds) ALGORITHM 

A ds algorithm is used by a signatory to generate a digital signature on data and by a verifier to 
verify the authenticity of the signature. Each signatory has a public and private key. The private key 
is used in the signature generation process and the public key is used in the signature verification 
process. For both signature generation and verification, the data which is referred to as a message, 
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M, is reduced by means of the Secure Hash Algorithm (SHA-1) specified in FIPS 180-1. An 
adversary, who does not know the private key of the signatory, cannot generate the correct signature 
of the signatory. In other words, signatures cannot be forged. However, by using the signatory's 
public key, anyone can verify a correctly signed message. A means of associating public and private 
key pairs to the corresponding users is required. That is, there must be a binding of a user's identity 
and the user's public key. This binding may be certified by a mutually trusted party. For example, 
a certifying authority could sign credentials containing a user's public key and identity to form a 
certificate. Systems for certifying credentials and distributing certificates are beyond the scope of 
this standard. NIST intends to publish separate document(s) on certifying credentials and distributing 
certificates. 

4. DSA PARAMETERS 

The DSA makes use of the following parameters: 

1 . p = a prime modulus, where 2 LA < p < 2 L for 5 12 < L < 1024 and L a multiple of 64 

2. q = a prime divisor of p - 1, where 2 159 < q < 2 160 

3. g = h^ 1 ^ mod p, where h is any integer with 1 < h < p - 1 such that mod p > 1 
(g has order q mod p) 

4. x = a randomly or pseudorandomly generated integer with 0 < x < q 

5. y = g x modp \ 

6. k = a randomly or pseudorandomly generated integer with 0 < k < q 

The integers p, q, and g can be public and can be common to a group of users. A user's private and 
public keys are x and y, respectively. They are normally fixed for a period of time. Parameters x 
and k are used for signature generation only, and must be kept secret. Parameter k must be 
regenerated for each signature. 

Parameters p and q shall be generated as specified in Appendix 2, or using other FIPS approved 
security methods. Parameters x and k shall be generated as specified in Appendix 3, or using other 
FIPS approved security methods. 

5. DSA SIGNATURE GENERATION 

The signature of a message M is the pair of numbers r and s computed according to the equations 
below: 
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r = (g k mod p) mod q and 

s = (k^SHA-UM) + xr)) mod q. 



In the above, k" 1 is the multiplicative inverse of k, mod q; i.e., (k' 1 k) mod q = 1 and 0 < k* ! < q. The 
value of SHA- 1 (M) is a 1 60-bit string output by the Secure Hash Algorithm specified in FIPS 180-1. 
For use in computing s, this string must be converted to an integer. The conversion rule is given 
in Appendix 2.2. - 

As an option, one may wish to check if r = 0 or s = 0. If either r = 0 or s = 0, a new value of k should 
be generated and the signature should be recalculated (it is extremely unlikely that r = 0 or s = 0 if 
signatures are generated properly). 

The signature is transmitted along with the message to the verifier. 

6. DSA SIGNATURE VERIFICATION 

Prior to verifying the signature in a signed message, p, q and g plus the sender's public key and 
identity are made available to the verifier in an authenticated manner. 

Let M', r', and s' be the received versions of M, r, and s, respectively, and let y be the public key of 
the signatory. To verify the signature/the verifier first checks to see that 0 < r' < q and 0 < s' < q; 
if either condition is violated the signature shall be rejected. If these two conditions are satisfied, 
the verifier computes 

w = (s')" 1 mod q 

ul = ((SHA-l(M0)w) modq 

u2 = ((Ow) mod q 

v =(((g) ul (y) u2 ) mod p) modq. 

If v = r', then the signature is verified and the verifier can have high confidence that the received 
message was sent by the party holding the secret key x corresponding to y. For a proof that v = i 
when NT = M, r' = r, and s' = s, see Appendix 1. 

If v does not equal r, then the message may have been modified, the message may have been 
incorrectly signed by the signatory, or the message may have been signed by an impostor. The 
message should be considered invalid. 



7, RSA DIGITAL SIGNATURE ALGORITHM 



The RSA ds algorithm is a FIPS approved cryptographic algorithm for digital signature generation 
and verification. This is described in ANSI X9.3 1 . 

8. ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA) 

The ECDSA ds algorithm is a FIPS approved cryptographic algorithm for digital signature 
generation and verification. ECDSA is the elliptic curve analogue of the DSA. ECDSA is 
described in ANSI X9.62. The recommended elliptic curves for Federal Government use are 
included in Appendix 6. 
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APPENDIX 1. A PROOF THAT v = r' IN THE DSA 



This appendix is for informational purposes only and is not required to meet the standard. 

The purpose of this appendix is to show that in the DSA, if M' = M, r' = r and s' = s in the signature 
verification then v = r'. We need the following easy result. 

LEMMA . Let p and q be primes so that q divides p - 1 , h a positive integer less than p, and g = h (p ' 
lVq mod p. Then g q mod p = 1 , and if m mod q = n mod q, then g m mod p = g" mod p. 

Proof: We have 
g q mod p = (h 0 " 1 ^ mod p) q mod p 
= h 0 " 0 mod p 
= 1 

by Fermat's Little Theorem. Now let m mod q = n mod q, i.e., m = n + kq for some integer k. Then 
g m mod p =g n+kq modp 
= (g n g kq )modp 

= ((g n mod p) (g q mod p) k ) mod p 
= g n mod p 
since g q mod p = 1 . ■ 

We are now ready to prove the main result. 

THEOREM . If M' = M, r' = r, and s' = s in the signature verification, then v = r'. 
Proof: We have 
w = (sO" 1 mod q = s" 1 mod q 

u 1 = ((SHA- 1 (M0)w) mod q = ((SHA- 1 (M))w) mod q 
u2 = ((r')w) mod q = (rw) mod q. 
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Now y = g x mod p, so that by the lemma, 
v = ((g ul y u2 ) mod p) mod q 
= ((gSHA-1^ y™) mod p) mod q 
= ((gSHA-l^ g xnv ) mod p) mod q 
= ((^SHA-l^*^) mod p) mod q. 

Also 

s = (k-'(SHA-l(M) + xr)) mod q. 
Hence 

w = (k(SHA-l(M) + xr) -1 ) mod q 
(SHA-1(M) + xr)w mod q = k mod q. 
Thus by the lemma, 
v = (g k mod p) mod q 
= r 

= r'. ■ 
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APPENDIX 2. GENERATION OF PRIMES FOR THE DSA 

This appendix includes algorithms for generating the primes p and q used in the DSA. These 
algorithms require a random number generator (see Appendix 3), and an efficient modular 
exponentiation algorithm. Generation of p and q shall be performed as specified in this appendix, 
or using other FIPS approved security methods. 

2.1. A PROBABILISTIC PRIMALITY TEST 

In order to generate the primes p and q, a primality test is required. 

There are several fast probabilistic algorithms available. The following algorithm is a simplified 
version of a procedure due to M.O. Rabin, based in part on ideas of Gary L. Miller. [See Knuth, The 
Art of Computer Programming, Vol. 2, Addison- Wesley, 1981, Algorithm P, page 379.] If this 
algorithm is iterated n times, it will produce a false prime with probability no greater than l/4 n . 
Therefore, n > 50 will give an acceptable probability of error. To test whether an integer is prime: 

Step 1. Set i = 1 andn> 50. 

Step 2. Set w = the integer to be tested, w = 1 + 2 a m, where m is odd and 2 a is the largest 
power of 2 dividing w - 1 . 

Step 3. Generate a random integer b in the range 1 < b < w. 

Step 4. Set j = 0 and z = b m mod w. 

Step 5. If j = 0 and z = 1, or if z = w - 1, go to step 9. 

Step 6. If j > 0 and z = 1, go to step 8. 

Step 7. j = j + 1 . If j < a, set z = z 2 mod w and go to step 5. 

Step 8. w is not prime. Stop. 

Step 9. If i < n, set i = i + 1 and go to step 3. Otherwise, w is probably prime. 

2.2, GENERATION OF PRIMES 
The DSA requires two primes, p and q, satisfying the following three conditions: 
a2 t59 <q<2 i60 

b. 2 L ' X < p < 2 L for a specified L, where L = 5 12 + 64j for some 0 < j < 8 
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c. q divides p - 1. 

This prime generation scheme starts by using the SHA-1 and a user supplied SEED to construct a 
prime, q, in the range 2 159 < q < 2 160 . Once this is accomplished, the same SEED value is used to 
construct an X in the range 2 L_1 < X < 2 L . The prime, p, is then formed by rounding X to a number 
congruent to 1 mod 2q as described below. 

An integer x in the range 0 < x < 2 g may be converted to a g-long sequence of bits by using its binary 
expansion as shown below: 

x = x 1 *2 g ' 1 + x 2 *2 g " 2 + ... + x g .,*2 + x g -> { x,,...,x g }. 

Conversely, a g-long sequence of bits { x,,...,x g } is converted to an integer by the rule 

{ x,,...,x g } -> x,*2 g -' + x 2 *2 g - 2 + ... + x g .,*2 + x g . 

Note that the first bit of a sequence corresponds to the most significant bit of the corresponding 
integer and the last bit to the least significant bit. 

Let L - 1 = n*160 + b, where both b and n are integers and 0 < b < 160. 

Step 1. Choose an arbitrary sequence of at least 160 bits and call it SEED. Let g be the length 
ofSEEDinbits. " - . 

Step 2. Compute 

U = SHA- 1 [SEED] XOR SHA- 1 [(SEED+ 1 ) mod 2 g J. 

Step 3. Form q from U by setting the most significant bit (the 2 159 bit) and the least significant 
bit to 1. In terms of boolean operations, q = U OR 2 159 OR 1. Note that 2 <q<2 . 

Step 4. Use a robust primality testing algorithm to test whether q is prime 1 . 

Step 5. If q is not prime, go to step 1 . 

Step 6. Let counter = 0 and offset = 2. 

Step 7. Fork = 0,...,nlet 

V k = SHA-1 [(SEED + offset + k) mod 2 g ]. 

'A robust primality test is one where the probability of a non-prime number passing the test is at 
most 2- 80 . 
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Step 8. Let W be the integer 

W - V 0 + V!*2 160 + ... + V n . 1 *2 (n - ])M6 ° + (V„ mod 2 b ) * 2 n * 160 
and let X = W + 2 L_I . Note that 0 < W < 2 L ' ! and hence 2 1 ' 1 < X < 2 L 
Step 9. Let c = X'mod 2q and set p = X - (c - 1). Note that p is congruent to 1 mod 2q. 
Step 10. If p < 2 L "\ then go to step 13. 
Step 1 1 . Perform a robust primality test on p. 
Step 12. If p passes the test performed in step 1 1, go to step 15. 
Step 13. Let counter = counter + 1 and offset = offset + n + 1 . 

Step 14. If counter > 2 12 = 4096 go to step 1, otherwise (i.e. if counter < 4096) go to step 7. 

Step 15. Save the value of SEED and the value of counter for use in certifying the proper 
generation of p and q. 
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APPENDIX 3. RANDOM NUMBER GENERATION FOR THE DSA 



Any implementation of the DSA requires the ability to generate random or pseudorandom integers. 
Such numbers are used to derive a user's private key, x, and a user's per message secret number, k. 
These randomly or pseudorandomly generated integers are selected to be between 0 and the 160-bit 
prime q (as specified in the standard). They shall be generated by the techniques given in this 
appendix, or using other FIPS approved security methods. 

One FIPS approved pseudorandom integer generator is supplied in Appendix C of ANSI X9.17, 
"Financial Institution Key Management (Wholesale)." 

Other pseudorandom integer generators are given in this appendix. These permit generation of 
pseudorandom values of x and k for use in the DSA. The algorithm in section 3. 1 may be used to 
generate values for x. An algorithm for k and r is given in section 3.2. The latter algorithm allows 
most of the signature computation to be precomputed without knowledge of the message to be 
signed. 

The algorithms employ a one-way function G(t,c), where t is 160 bits, c is b bits (160 < b < 512) and 
G(t,c) is 160 bits. One way to construct G is via the Secure Hash Algorithm (SHA-1), as defined 
in the Secure Hash Standard (SHS). The 160-bit message digest output of the SHA-1 algorithm 
when message M is input is denoted by SHA-1 (M). A second method for constructing G is to use 
the Data Encryption Standard (DES). The construction of G by these techniques is discussed in 
sections 3.3 and 3.4 of this appendix. * . 

In the algorithms in sections 3.1 and 3.2, a secret b-bit seed-key is used. The algorithm in section 
3. 1 optionally allows the use of a user provided input. If G is constructed via the SHA-1 as defined 
in section 3.3, then b is between 160 and 512. If DES is used to construct G as defined in section 
3.4, then b is equal to 160. 

3.1. ALGORITHM FOR COMPUTING m VALUES OF x 

Let x be the signer's private key. The following may be used to generate m values of x: 

Step 1 . Choose a new, secret value for the seed-key, XKEY. 

Step 2. In hexadecimal notation let 

t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0. 

This is the initial value for H 0 1| By \\ H 2 1| H 3 1| H4 in the SHS. 

Step 3. Forj =0 torn - 1 do 



16 



a. XSEEDj = optional user input. 

b. XV AL = (XKEY + XSEEDj) mod 2 b . - 

c. Xj = G(t,XVAL) mod q. 

d. XKEY = (1 + XKEY + Xj) mod 2 b . 

3.2. ALGORITHM FOR PRECOMPUTING ONE OR MORE k AND r VALUES 

This algorithm can be used to precompute k, k" 1 , and r for m messages at a time. Note that 
implementation of the DSA with precomputation may be covered by U.S. and foreign patents. 

Algorithm: 

Step 1. Choose a secret initial value for the seed-key, KKEY. 
Step 2. In hexadecimal notation let 

t = EFCDAB89 98BADCFE 10325476 C3D2E1F0 67452301. 
This is a cyclic shift of the initial value for H 0 || Hi || H 2 1| H 3 1| H4 in the SHS. 
Step 3. For j = 0 to m - 1 do 

a. k = G(t,KKEY) mod q. 

b. Compute k/ 1 = k" 1 mod q. 

c. Compute rj = (g k mod p) mod q. 

d. KKEY = (1 + KKEY + k) mod 2 b . 

Step 4. Suppose M 0 , ... , M m .i are the next m messages. For j = 0 to m - 1 do 

a. Leth = SHA-l(Mj). 

b. Let Sj = (kj _1 (h + xrj)) mod q. 

c. The signature for Mj is (rj,Sj). 
Step 5. Lett = h. 

Step 6. Go to step 3. 
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Step 3 permits precomputation of the quantities needed to sign the next m messages. Step 4 can 
begin whenever the first of these m messages is ready. The execution of step 4 can be suspended 
whenever the next of the m messages is not ready. As soon as steps 4 and 5 have completed, step 
3 can be executed, and the results saved until the first member of the next group of m messages is 
ready. 

In addition to space for KKEY, two arrays of length m are needed to store r 0 , ... r m .i and ko"\ ... , 
f 1 when they are computed in step 3. Storage for s 0 , ... , s m _i is only needed if the signatures for a 
group of messages are stored; otherwise sj in step 4 can be replaced by s and a single space allocated. 

3.3. CONSTRUCTING THE FUNCTION G FROM THE SHA-1 

G(t,c) may be constructed using steps (a) - (e) in section 7 of the Specifications for the Secure Hash 
Standard. Before executing these steps, {Hj} and Mi must be initialized as follows: 

i. Initialize the {Hj} by dividing the 160 bit value t into five 32-bit segments as follows: 

t = to || t, || t 2 || t 3 || U 
Then Hj = tj for j = 0 through 4. 

ii. There will be only one message block, M lr which is initialized as follows: 

Mi = c || 0 512 " b 

(The first b bits of Mi contain c, and the remaining (5 12-b) bits are set to zero). 

Then steps (a) through (e) of section 7 are executed, and G(t,c) is the 160 bit string represented by 
the five words: 

Ho || H, || H 2 || H 3 || H4 

at the end of step (e). 

3.4. CONSTRUCTING THE FUNCTION G FROM THE DES 

Let a XOR b denote the bitwise exchisive-or of bit strings a and b. Suppose al , a2, bl , b2 are 32-bit 
strings. Let bl' be the 24 least significant bits of bl . Let K = b 1* || b2 and A = al || a2. Define 

DES bl , b2 (al,a2) = DES K (A) 
In the above, DES K (A) represents ordinary DES encryption of the 64-bit block A using the 56-bit 
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key K. Now suppose t and c are each 160 bits. To compute G(t 9 c): 
Step 1. Write 

t = t, || t 2 || t 3 || t4 || t 5 
C = d || C 2 || C 3 || C 4 || C 5 

In the above, each ti and Cj is 32 bits. 
Step 2. For i = 1 to 5 do 

Xj = ti XOR Ci 
Step 3. For i= 1 to 5 do 

bl = C((i+3) mod 5) + 1 
b2 ~ c ((i+2) mod 5) + 1 
al = Xj 

a2 = X(i mod 5) + 1 XOR X((i+3) mod S) + 1 

y M || y it2 = DES b i >M (al,a2) (y u , y if2 = 32 bits) 
Step 4. For i = 1 to 5 do 

Zi = Yi,l XOR y((j+l) mod 5)+l,2 XOR y((i+2) mod 5)+l,l 

Step 5. Let 

G(t,c) = zi ||z 2 ||z 3 1| || Zs 
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APPENDIX 4. GENERATION OF OTHER QUANTITIES FOR THE DSA 

This appendix is for informational purposes only and is not required to meet the standard. 

The algorithms given in this appendix may be used to generate the quantities g, k" 1 , and s" 1 used in 
the DSA. 

To generate g: 

Step 1. Generate p and q as specified in Appendix 2. 

Step 2. Lete = (p- l)/q. 

Step 3. Set h = any integer, where 1< h < p - 1 and h differs from any value previously tried. 
Step 4. Set g = h c mod p. 
Step 5. If g = l,go to step 3. 
To compute the multiplicative inverse n" 1 mod q for n with 0 < n < q, where 0 < n 1 < q: 
Step 1. Set i = q, h = n, v = 0, and d = 1. 

Step 2. Let t = i DIV h, where DIV is defined as integer division. 

Step 3. Setx = h. 

Step 4. Set h = i - tx. 

Step 5. Set i = x. 

Step 6. Set x = d. . 

Step 7. Set d = v - tx. 

Step 8. Setv = x. 

Step 9. Ifh>0, gotostep2. 

Step 10. Let n 1 = v mod q. 

Note that in step 10, v may be negative. The v mod q operation should yield a value between 1 and 
q - 1 inclusive. 
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APPENDIX 5. EXAMPLE OF THE DSA 

This appendix is for informational purposes only and is not required to meet the standard. 
Let L = 512 (size of p). The values in this example are expressed in hexadecimal notation. The p 
and q given here were generated by the prime generation standard described in appendix 2 using the 
160-bit SEED: 

d5014e4b 60ef2ba8 b6211b40 62ba3224 e0427dd3 

With this SEED, the algorithm found p and q when the counter was at 105. x was generated by the 
algorithm described in appendix 3, section 3.1, using the SHA-1 to construct G (as in appendix 3, 
section 3.3) and a 1 60-bit XKEY: 

XKEY = 

bd029bbe 7f51960b cf9edb2b SlfOSfOf eb5a38b6 

t = 

67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 
x = G(t,XKEY) mod q 

k was generated by the algorithm described in appendix 3, section 3.2, using the SHA-1 to construct 
G (as in appendix 3, section 3.3) and a 160-bit KKEY: 

KKEY= ^ 

687a66d9 0648f993 867el21f 4ddf9ddb 012b5584 

t = 

EFCDAB8 9 98BADCFE 10325476 C3D2E1F0 67452301 

k = G(t,KKEY) modq 



Finally: 
h = 2 
P = 

8df2a494 492276aa 3d25759b b06869cb eac0d83a fb8d0cf7 
cbb8324f 0d7882e5 d0762fc5 b7210eaf c2e9adac 32ab7aac 
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49693dfb fS3724c2 ec0736ee 31c80291 

q = 

C773218C 737ec8ee 993b4f2d ed30f48e dace915f 

g = 

626d0278 39ea0al3 413163a5 5b4cb500 299d5522 956cefcb 
3bffl0f3 99ce2c2e 71cb9de5 fa24babf 58e5b795 21925c9c 
C42e9f6f 464b088c c572af53 e6d78802 

x - 

2070b322 3dba372f delcOffc 7b2e3b49 8b260614 

k = 

358dad57 1462710f 50e254cf Ia376b2b deaadfbf 

k-' = 

0d516729 8202e49b 4116acl0 4fc3f415 ae52f917 
M - ASCII form of "abc" (See FIPS PUB 180-1, Appendix A) 
(SHA-1)(M) = 

a9993e36 4706816a ba3e2571 7850c26c 9cdpd89d 

y = 

19131871 d75bl612 a819f29d 78dlb0d7 346f7aa7 7bb62a85 
9bfd6c56 75da9d21 2d3a36ef 1672ef66 0b8c7c25 5cc0ec74 
858fba33 f44c0669 9630a76b 030ee333 

r = 

8baclab6 6410435c b7181f95 bl6ab97c 92b341c0 

s = 

41e2345f If56df24 58f426dl 55b4ba2d b6dcd8c8 

w - 

9df4ece5 826be95f ed406d41 b43edc0b lcl8841b 
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bf655bd0 46f0b35e c791b004 804afcbb 8ef7d69d 



u2 = 

821a9263 12e97ade abcc8d08 2b527897 8a2df4b0 
g ul mod p = 

51blbf86 7888e5f3 af6fb476 9dd016bc fe667a65 aafc2753 
9063bd3d 2bl38b4c e02cc0c0 2ec62bb6 7306c63e 4db95bbf 
6f96662a 1987a21b e4ecl071 010b6069 

y u2 mod p = 

8b510071 2957e950 50d6b8fd 376a668e 4b0d633c Ie46e665 
5c611a72 e2b28483 be52c74d 4b30de61 a668966e dc307a67 
cl9441f4 22bf3c34 08aebalf 0a4dbec7 

V = 

8baclab6 6410435c b7181f95 bl6ab97c 92b341c0 
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APPENDIX 6. RECOMMENDED ELLIPTIC CURVES FOR FEDERAL 

GOVERNMENT USE 
July 1999 

This collection of elliptic curves is recommended for Federal government use and 
contains choices of private key length and underlying fields. 

1. Parameter Choices 

1.1 Choice of Key Lengths 

The principal parameters for elliptic curve cryptography are the elliptic curve 
E and a designated point G on E called the base point. The base point has order r, a 
large prime. The number of points on the curve is n =fr for some integer/(the 
cofactor) not divisible by r. For efficiency reasons, it is desirable to take the 
cofactor to be as small as possible. 

All of the curves given below have cofactors 1, 2, or 4. As a result, the 
private and public keys are approximately the same length. Each length is chosen to 
correspond to the cryptovariable length of a common symmetric cryptologic. In 
each case, the private key length is, at least, approximately twice the symmetric 
cryptovariable length. 

1.2 Choice of Underlying Fields 

For each cryptovariable length, there are given two kinds of fields. 

• A prime field is the field GF(p) which contains a prime number p of 
elements. The elements of this field are the integers modulo p, and the 
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field arithmetic is implemented in terms of the arithmetic of integers 
modulo p. 

• A binary field is the field GF(2 m ) which contains 2 m elements for some m 
(called the degree of the field). The elements of this field are the bit 
strings of length m, and the field arithmetic is implemented in terms of 
operations on the bits. 

The following table gives the sizes of the various underlying fields. By //p//is 

meant the length of the binary expansion of the integer/?. 

Symmetric Example 

CV Length Algorithm Prime Field Binary Field 

80 SKIPJACK ///>//= 192 m= 163 

112 Triple-DES "///?//= 224 m = 233 

128 AES Small ///V/= 256 " m = 283 

192 AES Medium ///?//= 384 m = 409 

256 AES Large ///V/= 521 m = 571 



1.3 Choice of Basis 

To describe the arithmetic of a binary field, it is first necessary to specify 
how a bit string is to be interpreted. This is referred to as choosing a basis for the 
field. There are two common types of bases: a polynomial basis and a normal basis. 
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• A polynomial basis is specified by an irreducible polynomial modulo 2, 
called the field polynomial. The bit string (a mA ...a 2 a\ a 0 )is taken to 
represent the polynomial 

a m .\t mA +...+ ctit 1 + a x t + oq 
over GF(2). The field arithmetic is implemented as polynomial arithmetic 
modulo p(t), where p(t) is the field polynomial. 

• A normal basis is specified by an element 9 of a particular kind. The bit. 
string (a 0 a x a 2 ...a m .\) is taken to represent the element 

aod+aiO 2 + a 2 6 2 + <Vi0 . 
Normal basis field arithmetic is not easy to describe or efficient to 
implement in general, but is for a special class called Type T low- 
complexity normal bases. For a given field degree m, the choice of T 
specifies the basis and the field arithmetic (see Appendix 6.2). 
There are many polynomial bases and normal bases from which to choose. The 
following procedures are commonly used to select a 'basis representation. 

• Polynomial Basis: If an irreducible trinomial f + f + 1 exists over GF 
(2), then the field polynomial pit) is chosen to be the irreducible trinomial 
with the lowest-degree middle term t k . If no irreducible trinomial exists, 
then one selects instead a pentanomial t m + f + t b + t c + 1 . The 
particular pentanomial chosen has the following properties: the second 
term f has the lowest degree m; the third term t b has the lowest degree 
among all irreducible pentanomials.of degree m and second term f\ and 
the fourth term f has the lowest degree among all irreducible 
pentanomials of degree m, second term f, and third term 
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• Normal Basis: Choose the Type T low-complexity normal basis with the 
smallest T. 

For each binary field, the parameters are given for the above basis representations. 

L4 Choice of Curves 

Two kinds of curves are given: 

• Pseudo-randomcurves are those whose coefficients are generated from 
the output of a seeded cryptographic hash. If the seed value is given 
along with the coefficients, it can be verified easily that the coefficients 
were indeed generated by that method. 

• Special curves whose coefficients and underlying field have been selected 
to optimize the efficiency of the elliptic curve operations. 

For each size, the following curves are given: 

— > A pseudo-random curve over GF(p). \ 
— » A pseudo-random curve over GF(2 m ). 

A special curve over GF(2 m ) called a Koblitz curve or anomalous binary 

curve. 

The pseudo-random curves are generated via the SHA-1 based method given in the 
ANSI X9.62 and IEEE PI 363 standards. (The generation and verification 
processes are given in Appendices 6-4 through 6-7.) 

1. 5 Choice of Base Points 
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Any point of order r can serve as the base point. Each curve is supplied with 
a sample base point G = (G x , G y ). Users may want to generate their own base 
points to ensure cryptographic separation of networks. 

2. Curves over Prime Fields 

For each prime p, a pseudo-random curve 

E: y 2 = x 3 -3x+b(modp) 
of prime order r is listedl . (Thus, for these curves, the cofactor is always/ = 1 .) 
The following parameters are given: 

• The prime modulus p 

• The order r 

• the 160-bit input seed s to SHA-1 based algorithm 

• The output c of the SHA-1 based algorithm 

• The coefficient b (satisfying b z c = -27 (mod p)) 

• The base point x coordinate G x ^ 

• The base point y coordinate G y 

The integers p and r are given in decimal form; bit strings and field elements are 
given in hex. 



1 The selection a 



s -3 for the coefficient of x was made for reasons of efficiency; see IEEE PI 363. 
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Curve P-192 

62771017353866807638357894232076664160839087\ 
00390324961279 

62771017353866807638357894231760590137671947\ 
73182842284081 

3045ae6f c8422f64 ed579528 d38120ea el2196d5 

3099d2bb 

bfcb2538 542dcd5f b078b6ef 5f3d6fe2 c745de65 

64210519 

e59c80e7 0fa7e9ab 72243049 feb8deec cl46b9bl 

188da80e 

b03090f6 7cbf20eb 43al8800 f4ff0afd 82fF1012 

07192b95 

ffc8da78 63101 led 6b24cdd5 73f977al le794811 
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Curve P-224 

26959946667150639794667015087019630673557916\ 
260026308143510066298881 

26959946667150639794667015087019625940457807\ 
7 1 442439 1 72 1 68272236806 1 

bd7 13447 99d5c7fc dc45b59f a3b9ab8f 6a948bc5 

5b056c7e Ildd68f4 
0469ee7f3c7a7d74 f7dl2111 6506d031 218291fb 

b4050a85 0c04b3ab 
f54 13256 5044b0b7 d7bfd8ba 270b3943 2355ffb4 

b70e0cbd 6bb4bf7f 
321390b9 4a03cld3 56c21122 343280d6 1 15cld21 

. bd376388 b5f723fb 
4c22dfe6 cd4375a0 5a074764 44d58199 85007e34 
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Curve P-256 

11579208921035624876269744694940757353008614\ 
341 52903 1419553363 1 30886709785395 1 
11579208921035624876269744694940757352999695\ 
5224135760342422259061068512044369 

c49d3608 86e70493 6a6678el 139d26b7 819f7e90 

7efbal66 2985be94 03cb055c 
75d4f7e0 ce8d84a9 c51 14abc aD 17768 0104fa0d 
b = 5ac635d8 aa3a93e7 b3ebbd55 

769886bc 651d06b0 cc53b0f6 3bce3c3e 27d2604b 
G x = 6bl7dlf2 el2c4247 f8bce6e5 

63a440f2 77037d81 2deb33a0 f4al3945 d898c296 
G y = 4fe342e2 fela7f9b 8ee7eb4a 



P = 
r ~ 

s = 
c = 



7c0f9el6 2bce3357 6b315ece cbb64068 37bf51f5 
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Curve P-384 

39402006 1 963944792 1 2279040 1 00 1 43 6 1 3 80507973 9\ 

27046544666794829340424572 1 77 149687032904726\ 

6088258938001861606973112319 

39402006 1 963944792 1 2279040 1 00 1 43 6 1 3 80507973 9\ 

2704654466679469052796276593991 1326356939895\ 

6308 1 5229491 3554433653942643 

a335926a a319a27a ld00896a 6773a482 7acdac73 

79dle655 f868f02f 
ff48dcde el4151dd b80643cl 406d0cal 0dfe6fc5 
2009540a 495e8042 ea5f744f 6e 184667 cc722483 

b3312fa7 e23ee7e4 
988e056b e3f82dl9 181d9c6e fe814112 0314088f 
5013875a c656398d 8a2edl9d~2a85c8ed d3ec2aef 

aa87ca22 be8b0537 
8eblc71e f320ad74 6eld3b62 8ba79b98 59f741e0 
82542a38 5502f25d bf55296c 3a545e38 72760ab7 

3617de4a96262c6f 
5d9e98bf 9292dc29 f8f41dbd 289al47c e9da31 13 
b5f0b8c0 0a60blce Id7e819d 7a431d7c 90ea0e5f 
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Curve P-521 

6864797660 1 306097 1498 1 90079908 1 3932 1 72694353\ 

00143305409394463459185543183397656052122559\ 

64066145455497729631 139148085803712198799971\ 

6643812574028291115057151 

6864797660 1 306097 1498 1 90079908 1 3932 1 72694353\ 

00143305409394463459185543183397655394245057\ 

746333217197532963996371363321 1 138647686 1244\ 

0380340372808892707005449 

d09e8800 291cb853 96cc6717 393284aa a0da64ba 

0b4 8bfa5f42 
0a349495 39d2bdfc 264eeeeb 077688e4 4fbf0ad8 
f6d0edb3 7bd6b533 28100051 8el9flb9 ffbe0fe9 
ed8a3c22 00b8f875 e523868c 70cle5bf 55bad637 

051 953eb961 
8elc9alf 929a21a0 b68540ee a2da725b 99b315f3 
b8b48991 8efl09el 56193951 ec7e937b 1652c0bd 
3bblbf07 3573df88 3d2c34fl ef451fd4 6b503f00 

c6 858e06b7 

0404e9cd 9e3ecb66 2395b442 9c648139 053fb521 
f828af60 6b4d3dba al4b5e77 efe75928 feldcl27 
a2ffa8de 3348b3cl 856a429b f?7e7e31 c2e5bd66 

118 39296a78 
9a3bc004 5c8a5fb4 2c7dlbd9 98f54449 579b4468 
17afbdl7 273e662c 97ee7299 5ef42640 c550b901 
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3fad0761 353c7086 a272c240 88be9476 9fdl6650 



3. Curves over Binary Fields 

For each field degree m, a pseudo-random curve is given, along with a 
Koblitz curve. The pseudo-random curve has the form 

E: y 2 + xy = x 2 + x 2 + b, 
and the Koblitz curve has the form 

E a : y + xy= x 2 + ax 2 + 1 

where a = 0 or 1 . 

For each pseudorandom curve, the cofactor is/= 2. The cofactor of each 
Koblitz curve is/= 2 if a = 1 and/= 4 if a = 0. 

The coefficients of the pseudo-random curves, and the coordinates of the 
base points of both kinds of curves, are given in terms of both the polynomial and 
normal basis representations discussed in 1.3. 
For each m, the following parameters are given: 
Field Represen ta tion : 

• The normal basis type T 

• The field polynomial (a trinomial or pentanomial) 
Koblitz Curve: 

• The coefficient a 

• The base point order r 

• The base point x coordinate G x 

• The base point y coordinate G y 
Pseudo-random curve: 

• The base point order r 
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Pseudo-random curve (Polynomial Basis representation): 

• The coefficient b 

• The base point x coordinate G x 

• The base point y coordinate G y 
Pseudo-random curve (Normal Basis representation): 

• The 160-bit input seed s to the SHA-1 based algorithm 

• The coefficient b (i.e., the output of the SHA-1 based algorithm) 

• The base point x coordinate G x 

• The base point y coordinate G y 

Integers (such as T, m, and r) are given in decimal form; bit strings and 
field elements are given in hex. 
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Degree 233 Binary Field 



r=2 

P {t) = t™ + t u + 1 



Curve K-233 



a = 0 

r =3450873 17339528 1 89371737793 1 1385 12760570940988862252 1\ 
26328087024741343 
Polynomial Basis: 

172 32ba853a7e731afl 
29f22ff4 149563a4 19c26bf5 0a4c9d6e efad6126 

ldb 537dece8 19b7f70f 
555a67c4 27a8cd9b fl8aeb9b 56e0cll0 56fae6a3 



G y = 



Normal Basis: 



Ofd e76d9dcd 26e643ac 
26flaa90 laa 12978 4b71fc07 22b2d056 14d650b3 

064 3e3 17633 155c9e04 
47ba8020 a3c43177 450ee036 d6335014 34cac978 
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Curve B-233 



r = 69017463467905637874347558622770255558398'127373450135\ 
55379383634485463 
Polynomial Basis: 

066 647ede6c 332c7f8c 
0923bb58 213b333b 20e9ce42 81fel 15f 7d8f90ad 

0fac9dfcbac8313bb21 
39flbb75 5fef65bc 391f8b36 fBf8eb73 71fd558b 

100 6a08a419 03350678 
e58528be bfBaObef f867a7ca 36716f7e 01f81052 



b = 



G y = 



Normal Basis: 
s = 
b = 



74d59ff0 7f6b413d 0eal4b34 4b20a2db 049b50c3 
" - - Ia0 03e0962d4f9a8e40 

7c904a95 38163adb 82521260 0c7752ad 52233279 

18b'863524b3 cdfefb94 
f2784e0b 116faac5 4404bc91 62a363bab84al4c5 

049 25df77bd 8b8ffla5 
ff519417 822bfedf 2bbd7526 44292c98 c7af6e02 
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Degree 283 Binary Field 



T=6 

p{t) = t 2 ^ + t n + t 1 + t 5 + 1 

Curve K-283 

a = 0 

r= 388533778445145814183892381364703781328481 17337930613\ 
24295874997529815829704422603873 
Polynomial Basis: 

G x = 503213f 78ca4488 3fla3b81 62fl88e5 

53cd265f 23cl567a 16876913 b0c2ac24 58492836 
G y = lccda38 0flc9e31 8d90f95d 07e5426f 

e87e45c0 e8184698 e4596236 4e341161 77dd2259 

Normal Basis: 

G x = 3ab9593 f8db09fc 1 88fl d7c 4ac9fcc3 

e57fcd3b dbl 5024b 212c7022 9de5fcd9 2eb0ea60 

G y = 211 8c47 55e7345c d8f603ef 93b98bl 0 

6fe8854f feb9a3b3 04634cc8 3a0e759f 0c2686bl 
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Curve B-283 



r = 77706755689029162836778476272940756265696259243769048\ 
89109196526770044277787378692871 
Po lynomia I Basis : 

27b680a c8b8596d a5a4af8a 19a0303f 
ca97fd76 45309fa2 a58 1485a f6263e31 3b79a2f5 

5f93925 8db7dd90 el934f8c 70b0dfec 
2eed25b8 557eac9c 80e2el98 f8cdbecd 86bl2053 

3676854 fe24141c b98fe6d4 b20d02b4 
516ff702 350eddb0 826779c8 13fOdf45 be8112f4 



b = 



G y = 



Normal Basis: 
s = 
b = 



77e2b073 70eb0f83 2a6dd5b6 2dfc88cd 06bb84be 
157261b 894739fb 5al3503f 55f0b3fl 

0c560116 66331022 01 138ccl 80c0206b dafbc951 
749468e 464ee468 634b21f7 f61cb700 

701817e6 bc36a236 4cb8906e 940948ea a463c35d 

62968bd 3b489ac5 c9b859da 68475c31 5bafcdc4 
ccd0dc90 5b70f624 46f49c05 2f49c08c 
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Degree 409 Binary Field 

T= 4 
p{t) = t m + t sl + \ 



Curve K-409 

a = 0 

r = 33052798439512429947595765401638551991420234148214060\ 
964232439502288071 12892491910506732584577774580140963\ 
66590617731358671 
Polynomial Basis: 

060f05f 658f49cl ad3abl89 
0f7 18421 0efd0987 e307c84c 27accfb8 f9f67cc2 
c460189e b5aaaa62 ee222ebl b35540cf e9023746 

" le36905 0b7c4e42 acbaldac 
bf04299c 3460782f 918ea427 e6325165 e9eal0e3 
da5f6c42 e9c55215 aa9ca27a 5863ec48 d8e0286b 



G x = 



Normal Basis: 
G x = 



G y = 



Ib559c7 cba2422e 3affel33 
43e808b5 5e012d72 6ca0b7e6 a63aeafb cle3a98e 
lOcaOfcf 98350c3b 7f89a975 4a8eldc0 713cec4a 

16d8c42 052f07e7 713e7490 
eff318ba Iabd6fef .8a5433c8 94b24f5c 817aeb79 
852496fb ee803a47 bc8a2038 78ebflc4 99afd7d6 
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Curve B-409 



b = 



r = 66105596879024859895191530803277103982840468296428121\ 
92846487983041577748273748052081437237621791 109659798\ 
67288366567526771 
Po lynomia I Basis : 

021a5c2 c8ee9feb 5c4b9a75 
3b7b476b 7fd6422e flf3dd67 4761fa99 d6ac27c8 
a9al97b2 72822f6c d57a55aa 4f50ae31 7bl3545f 
15d4860 d088ddb3 496b0c60 
64756260 441cde4a fl771d4d b01ffe5b 34e59703 
dc255a86 8al 18051 5603aeab 60794e54 bb7996a7 

061blcf ab6be5f3 2bbfa783 
24edl06a 7'636b9c5 a7bdl98d 0158aa4f 5488d08f 
38514flf df4b4f40 d2181b36 81c364ba 0273c706 



G x = 



G y = 



Normal Basis: 
s = 
b = 



G x = 



G y = 



4099b5a4 57f9d69f 79213d09 4c4bcd4d 4262210b 

124d065 Ic3d3772f7f5alfe 
6e715559 e2129bdf a04d52f7 b6ac7c53 2cf0ed06 
f610072d 88ad2fdc c50c6fde 72843670 f8b3742a 

Oceacbc 9f475767 d8e69f3b 
5dfab398 13685262 bcacf22b 84c7b6dd 981899e7 
318c96fO 761f77c6 02c016ce d7c548de 830d708f 

199d64b a8f089c6 db0e0b61 
e80bb959 34afd0ca f2e8be76 dlc5e9af fc7476df 
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49142691 ad303902 88aa09bc c59cl573 aa3c009a 
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Degree 571 Binary Field 



T= 10 

p(t) = t 5n + t i0 + t 5 + t 2 +\ 



Curve K-571 



a = 0 



r=19322687615086291723476759454659936721494636648532174\ 
99328617625725759571 14478021226813397852270671 1834706\ 
71280082535146127367497406661731 192968242161709250355\ 
5733685276673 
Polynomial Basis: 

26eb7a8 59923fbc 82189631 
f8103fe4 ac9ca297 0012d5d4 60248048 01841ca4 
43709584 93b205e6 47da3(Md b4ceb08c bbdlba39 
494776fb 988b4717 4dca88c7 e2945283 a01c8972 

349dc80 7f4fbf37 4f4aeade 
3bca9531 4dd58cec 9f307a54 ffc61efc 006d8a2c 
9d4979c0 ac44aea7 4fbebbb9 f772aedc b620b0 1 a 
7ba7aflb 320430c8 591984f6 01cd4cl4 3eflc7a3 



Normal Basis: 
G x = 



04bb2db a418d0db 107adae0 
03427e5d 7ccl39ac b465e593 4f0bea2a b2f3622b 
c29b3d5b 9aa7alfd fd5d8be6 6057ci00 8e71e484 
bcd98f22 bf847642 37673674 29ef2ec5 bc3ebcf7 
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44cbb57 de20788d 2c952d7b 
56cf39bd 3e89bl89 84bdl24e 751ceff4 369dd8da 
c6a59e6e 745df44d 8220ce22 aa2c852c fcbbef49 
ebaa98bd2483e331 80e04286 feaa2530 50caff60 
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Curve B-571 



b = 



r= 38645375230172583446953518909319873442989273297064349V 
98657235251451519142289560424536143999389415773083133\ 
881 12192694448624687246281681307023452828830333241 139\ 
3191105285703 
Po lynomia I Bas is : 

2f40e7e 2221f295 de297117 
b7f3d62f 5c6a97ff cb8ceffl cd6ba8ce 4a9al8ad 
84ffabbd 8efa5933 2be7ad67 56a66e29 4afdl85a 
78ffl2aa 520e4de7 39baca0c 7ffeff7f 2955727a 
303001d 34b85629 6cl6c0d4 
0d3cd775 0a93dld2 955fa80a a5f40fc8 db7b2abd 
bde53950 f4c0d293 cdd711a3 5b67fbl4 99ae6003 
8614A39 4abfa3b4 c850d927 ele7769c 8eec2dl9 

37bf273 42da639b 6dccfffe 
b73d69d7 8c6c27a6 009cbbca 1980fB53 3921e8a6 
84423e43 bab08a57 6291af8f 461bb2a8 b3531d2f 
0485cl9b 16e2fl51 6e23dd3c la4827af Ib8acl5b 



G x = 



G y = 



Normal Basis: 
s = 
b = 



G x = 



2aa058f7 3a0e33ab 486b0f61 0410c53a 7A32310 
3762d0d47116006 179da356 
88eeaccf 591a5cde. a7500011 8d9608c5 9132d434 
26101aldfb377411 5f586623 f75fOOOO lce61198 
3cl275fa 31f5bc9f 4bela0f4 67f01ca8 85c74777 
0735e03 5def5925 cc33173e 
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b2a8ce77 67522b46 6d278b65 0a291612 7dfea9d2 
d361089f 0a7a0247 al84elc7 Od4 17866 eOfeOfeb 
0ff8f2f3 f9176418 f97dl 17e 624e2015 dfl662a8 
04a3642 0572616c df7e606f 
ccadaecf c3b76dab 0ebl248d d03fbdfc 9cd3242c 
4726be57 9855e812 de7ec5c5 00b4576a 24628048 
b6a72d88 0062eedO dd34bl09 6d3acbb6 b01a4a97 
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APPENDIX 6.1: IMPLEMENTATION OF MODULAR ARITHMETIC 

The prime moduli in the above examples are of a special type (called 
generalized Mersenne numbers) for which modular multiplication can be carried 
out more efficiently than in general. This appendix provides the rules for 
implementing this faster arithmetic, for each of the prime moduli appearing in the 
examples. 

The usual way to multiply two integers (mod m) is to take the integer 
product and reduce it (mod m). One therefore has the following problem: given an 
integer A less than m 2 , compute 

B := A mod m. 

In general, one must obtain B as the remainder of an integer division. If m is 
a generalized Mersenne number, however, then B can be expressed as a sum or 
difference (mod m) of a small number of terms. To compute this expression, one 
can evaluate the integer sum or difference and reduce the result modulo m. The 
latter reduction can be accomplished by adding or subtracting a few copies of m. 

The prime moduli p for each of the five example curves is a generalized 
Mersenne number. 
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Curve P- 192: 

The modulus for this curve is p= 2 192 - 2 64 - 1 . Every integer A less than p 2 
can be written 

A -A s - 2 320 + A 4 • 2 256 + A, ■ 2 m + A 2 • 2 128 + A x ■ 2 M + A Q , 
where each A t is a 64-bit integer. The expression for B is 

5 := T+ Si + Si + 5 mod/?; 
where the 192-bit terms are given by 

T = A 2 -2 m +A l -2 64 +A 0 
S x = A 3 -2 64 + Ai 

S 2 =A 4 -2 n *+A 4 -2 64 
Si=A 5 -2 l2S +A 5 - 2 64 +^ 5 . 
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Curve P-224: 

The modulus for this curve is p = 2 224 - 2 96 + 1 . Every integer A less than 
p 2 can be written 

A=A iy 2 M6 + An-2™+ A ir 2> 52 + A l0 -2 320 + A 9 -2™ + A s -2 256 + ^-2 224 + 
^•2 192 + A 5 -2 m + A 4 -2™+ A 3 - 2 96 + A 2 -2 64 + A x -2 n + A,, 
where each A t is a 32-bit integer. As a concatenation of 32-bit words, this can be 
denoted by 

A= {A n ll Anil- ■ -//A 0 ). 

The expression for B is 

B:=T+ Si + Si-Dx - D 2 modp, 
where the 224-bit terms are given by 

T= ( 4 Ms || ^4 II ^3 1| A 2 \[A X \\A,) 
Sx={A w \\A 9 \\ AzW^W 0 || 0 || 0 ) 
S 2 = ( 0 M13IM12IM11H 0 || 0 || 0 ) ^ 
A =(^.3 M12H An\\A l0 \\ A 9 \\ Ai\\A 7 ) 
D 2 = ( 0 || 0 || 0 || 0 1^,3 M12H A u ). 
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Curve P-2 56: 

The modulus for this curve is p = 2 256 - 2 224 + 2 192 + 2 96 - 1 . Every integer A 
less than p 2 can be written 

A =A l5 -2 m + A H -2 m + A n -2 4l6 + A l2 -2 m + A n • 2 352 + 

4o-2 320 + A-2 288 + 4r 2 256 + ^ 7 - 2 224 + A 6 -2 l92 + A 5 -2 m + 

A 4 -2 m + A r 2 96 + A 2 -2 64 + A r 2*+ A 0 , 
where each A ,• is a 32-bit integer. As a concatenation of 32-bit words, this can be 
denoted by 

A=(A, 5 \\A H \\---\\A 0 ). 

The expression for B is 

B:=T+2S X + 2S 2 + S 3 + S 4 - D x - D 2 - D 2 - D 4 modp, 
where the 256-bit terms are given by 



r- ( a 7 


I 4 || 4 


II ^ || A, || 


'4 || A x || 4) 


5, = ( A l5 \ 


1^14 || A 12 


IMnll 4i| 


0 || 0 ||,0 ) 


S 2 = ( o 


\\A l5 \\A l4 


II A l2 \\A l2 \ 


| 0 || 0 || 0 ') 


$»( 4s| 


\A l4 \\ 0 


II 0 || 0 


IMioll A 9 || At) 


S 4 = ( ^ | 


\An\\ Am 


Mu|| A„\ 


An\\A l0 1| A 9 ) 


£>i = (4o 


II -M || 0 


II o || 0 


|| 4 3 |Mi 2 || 4i) 


£>2 = (4l| 


M9 II o 


II 0 \\A l5 


|| |Ml3 M12 ) 


Di=(A l2 \ 


| 0 || A l0 


II A 9 || ^ | 


An Ml4|| 4 3 ) 




1 0 


II || A 9 || 


0 || ^15 || ^14 )• 
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Curve P-384: 

The modulus for this curve is p = 2 384 - 2 128 - 2 96 + 2 32 - 1 . Every integer A 

less than p 2 can be written 

A=A 2r 2 m + A 22 -2™ + A 2X -2 m + A 20 -2 640 + A l9 -2 m + 
A xs -2 516 + A xl -2 544 + A x6 -2 5 » + A l5 -2™ + A x <-2™ + ^ 13 -2 416 + A x2 
■ 2 384 + A n - 2 352 + An- 2 320 + 2 288 + - 2 256 + - 2 224 + 
4,- 2 192 + 2 160 + A,- 2 128 + ^ 2 96 + 2"+ ^, • 2 32 + 4,, 

where each A , is a 32-bit integer. As a concatenation of 32-bit words, this can be 

denoted by 

A=(A 2 ,\\A 22 ||---iMo). 

The expression for B is 

B := T + 2S X + S 2 + S 3 + S 4 + S 5 + S 6 - D x - D 2 - Z) 3 mod p, 
where the 384-bit terms are given by 

T= {A n \\Av>\\A 9 \\ A % \\ A 1 \\ A 6 \\ A 5 \\A 4 \\A 3 \\A 2 \\ A, \\ A 0 ) 

51 = ( 0 || 0 || 0 || 0 || 0 || A 23 \\ ^11^,110 || 0 || 0 || 0) 

5 2 = (A 23 1| A 22 || A 2X || A 20 1| A ]9 || An \\An\\ A l6 1| A l5 \\ A l4 \\ A n \\ A X2 ) 
Sz = (A 20 1| A l9 || A x $ 1| A n || A ]6 \\ A l5 \\ A H \\ A xl \A X2 \\ A 2l \ A 22 \ A 2X ) 
S 4 ^(A x9 \\An\\A ll \\A l6 \\A l5 \\A u \\A n \\ A l2 \\A m \\ 0 || A 2 , || 0 ) 
Ss = ( 0 || 0 || 0 || 0 || ^ 2 3 M22 M21 M20 || 0|| 0 1| 0 || 0 ) 
S 6 = ( 0 || 0 || 0 || 0 || 0 || 0 || A 23 \\Aj2 M21H 0 || 0|| A 20 ) 
D x = (A 22 1| A 2l || A 20 \\ A x9 \\ A xz \\ A„ || A x6 \\ A x5 \\ A XA \\ A l3 \\A X2 \\ A 23 ) 
D 2 = (0 || 0 || 0 || 0 || 0 || 0 H 0 || A 22 \\A 22 \\A 2 \\ A 20 || 0) 

D 3 = ( 0|| 0 || 0 || 0 || 0 || 0 || 0 M23 II ^23 II 0 1| 0 || 0). 
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Curve P-521: 

The modulus for this curve is p = 2 521 - 1 . Every integer A less than p 2 
be written 

A=A r 2 52l +A 0 , 

The expression for B is 

B :=Ao + A\ mod/? 
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APPENDIX 6.2: NORMAL BASES 

The elements of GF(2 m ) are expressed in terms of the type T normal 

basis 2 B for GF(2 m ), for some T. Each element has a unique representation 

as a bit string 

( a 0 a x . . . a m .\ ) 
The arithmetic operations are performed as follows. 

Addition : addition of two elements is implemented by bitwise addition modulo 2. 
Thus, for example, 

(1100111) + (1010010) = (0110101). 

Squaring , if 

a=(a 0 a x . . . a mA ) 

then 

tt 2 = (a m -\ a 0 a\ . . . a m _ 2 ) 
Multiplication : to perform multiplication, one first constructs a function F(u, v) on 
inputs 

u = (u 0 u\ . . . u m .\ ) and v = ( v 0 vi . . . v mA ) 

as follows. 

1. • Set/?<-7m + l 

2. Let u be an integer having order T modulo p 



2 It is assumed in this section that m is odd and T is even, since this is the only case considered in this standard. 
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* * 

3. Compute the sequence F (1); F {!),..., F 0-1) as follows: 

3.1 Set w<- 1 

3.2 For; from 0 to T-\ do 

Set n <—w 

For z from 0 to m-l do 

Set F(n) <- i 

Set n <r- In mod 
Set wf-uw mod 

4. Output the formula 

p-2 

^(M. v) : = % u F( k+\) v F(p . k) . 

4=1 

This computation need only be performed once per basis. 
Given the function F for B, one computes the product 

( c 0 C\ . . . c m .\ ) = ( a 0 a\ . . . a mA ) x ( b 0 b x . > . 6 m .i ) 
as follows. 

1. Set (uq U\ . . . u m .\ ) <— ( a 0 a\ . . . a m .\ ) 

2. Set ( v 0 vi . . . v m .i ) ( £? 0 b\ . . . 2vi ) 

3. For A: from 0 to m - 1 do 

3.1 Compute 

Ck ■= F(u, v) 

3.2 Set w <- LeftShift (u) and v <- LeftShift (v), where LeftShift 
denotes the circular left shift operation. 

4. Output c := ( c 0 Ci . . . c m .i ) 
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EXAMPLE. For the type 4 normal basis for GF(2 7 ), one has p = 29 and 

u = 12 or 17. Thus the values of F are given by 

F(1) = 0 F(8) = 3 F(15) = 6 F(22) = 5 
F(2)=l F(9) = 3 F(16) = 4 F(23) = 6 
F(3) = 5 F(10) = 2 F(17) = 0 F(24) = l 
F(4) = 2 F(ll) = 4 F(18) = 4 F(25) = 2 
F(5)=l F(12) = 0 F(19) = 2 F(26) = 5 
F(6) = 6 F(13) = 4 F(20) = 3 F(27) = l 
F(7) = 5 F(14) = 6 F(21) = 3 F(28) = 0 

Therefore 

F (u; v) = t* vi + «i (v 0 + \>> + v 5 + v 6 ) + ^ Oi + vj + v 4 + vs ) 
+ "3 (v 2 + ^ ) + tk (v 2 + v 6 ) + us (vi + ^ + Vs + v& ) 

+ U 6 (Vi + V 4 + V5 + V 6 ). . 

Thus, if 

a = (1 0 1 0 1 1 1) and b = (1 1 0 0 0 0 1), . 

then 

c 0 = F((1 0 1 0 1 1 1),(1 1 0000 1)) = 1, 
d = F((0 1 0 1 1 1 1),(1 0000 1 1)) = 0, 

c 6 = F((l 10101 1);(1 1 1 0000))= 1, 
sothatc = a£ = (l 0 110 0 1). 
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APPENDIX 6.3: SCALAR MULTIPLICATION ON KOBLITZ CURVES 

This appendix describes a particularly efficient method of computing the 
scalar multiple nP on the Koblitz curve E a over GF(2 m ). 
The operation x is defined by 

r(x,y) = (x 2 ,y 2 ) 

When the normal basis representation is used, then the operation t is 
implemented by performing right circular shifts on the bit strings representing x and 

y- 

Given m and a, define the following parameters: 

• C is some integer greater than 5. 

• For / = 0 and / = 1, define the sequence by 

5,(0) = 0, 'j,(l) = l-f, 
Si (m) = jl . sim - 1) - 2 S 0n - 2) + (-1)'' 

• Define the sequence V{m) 

F(0) = 2, V{\)=ii 
V(m)= fl*v(m-l)-2V(m-2). 
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For the example curves, the quantities Sj(m) and V(m) are as follows. 
Curve K- 163: 

5 0 (163) = 25793864391 10731650419537 

5,(163) = -755360064476226375461594 

V(163) = -4845466632539410776804317 

Curve K-233: 

<? 0 (233) = -27859711741434429761757834964435883 
Ji(233) = -44192136247082304936052160908934886 
V(233) = -13738154601 1 108235394987299651366779 

Curve K-283: 

5 0 (283) = -6659815321 0904904 1 1 08795 53 600 1 5 9 1 469280025 
5,(283) = 1155860054909136775192281072591609913945968 
K(283) = 77772448708728309992877919709^2823977569917 

Curve K-409: 

5 0 (409) = -1830751045600238213781031719875646137859054248755686\ 
9338419259 

j,(409) = -8893048526138304097196653241844212679626566100996606\ 
444816790 

K(409)=1045728873731562592744768538704832073763879695768757\ 
5791173829 

Curve K-571: 
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j 0 (571) = -37373 1 94468764636924293 85892476 1155671 47293964596 1 3\ " 

1 024 1 2340642023524 1 9 1 672998326 1305 
j 1 (571) = -3191857706446416099583814595948959674131968912148564\ 

65861056511758982848515832612248752 
V(51 1)=- 1 483 8092698 1 69 14 1 38996 1 9 14029705 14903645425741 80493\ 

936232912339534208516828973111459843 

The following algorithm computes the scalar multiple nP on the Koblitz 
curve E a over GF(2 m ). The average number of elliptic additions and subtractions 
at most ~ 1 + (m/3), and is at most ~ m/3 with probability at least 1 - 2 " . 

For i = 0 to 1 do 

n'ir- l n /2 a - c ^ m - 9)ll \ 
g sim) ■ n' 
h'*-lg'l2 m \ 

r*-Rowid((g'+j')/2 {m+5)l2 ) 

A,«-/72 c 

/ Round^ 

T] <r- 2 r/o + M T7i - 

If 77 ^ 1 

then 
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if7] 0 -3 /i77i <-l 

then set h\ <— [i 
else set h 0 <- 1 

else 

if 77o +4/X7]!>2 

then set 1 «— /i 

If 77 <r-l 
then 

if 770 - 3 \i 771 > 1 

then set h\<r- - fi 
else set h 0 <— -1 

else 

if 770 + 4 771 < -2 

then set hi <r- - fi 

qo «-/o + ^0 

r 0 «- « - (s 0 + fl ^i) qo - 2s x q\ 
r\ <-s x q 0 - So q x 
Set Q <r- O 
Po^P 

While r 0 *0 or n *0 
If r 0 odd then 

set u «- 2 - (r 0 - 2 n mod 4) 
set r 0 <r- r 0 -u 
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if u = 1 then set O <- O + P 0 
if u = -1 then set Q 4- Q - P Q 
SetP 0 <- tPo 

Set (r 0 , n) <r- (r, + /ir 0 fl, - r 0 /I) 
Endwhile •• 
Output Q 
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APPENDIX 6.4: GENERATION OF 
PSEUDO-RANDOM CURVES (PRIME CASE) 

Let / be the bit length of p, and define 

v =L(/- l)/160j 
w =1- 160v- 1 

1. Choose an arbitrary 160-bit string s. 

2. Compute /t:=SHA- l(s). 

3. Let ho be the bit string obtained by taking the w rightmost bits of h. 

4. Let z be the integer whose binary expansion is given by the 1 60-bit string s. 

5. For i from 1 to v do: 

5.1 Define the 1 60-bit string s t to be binary expansion of the integer 
(z + Omod (2 160 ). 

5.2 Compute A,- :=SHA-l(j/). 

6. Let h be the bit string obtained by the concatenation of h 0 ,h h ... , h v as follows: 

h = h 0 \\h x ||...|| ^ 

7. Let c be the integer whose binary expansion is given by the bit string h. 

8. If c = 0 or 4c + 27 s 0 (mod p), then go to Step 1 . 

9. Choose integers a, be GF(p) such that 

cb 2 = a l (mod p). 

(The simplest choice is a = c and b = c. However, one may want to choose 
differently for performance reasons.) 

10. Check that the elliptic curve E over GF(p) given by y 1 = x 3 + ax + b has 
suitable order. If not, go to Step 1 . 
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APPENDIX 6.5: VERIFICATION OF CURVE 
PSEUDO-RANDOMNESS (PRIME CASE) 

Given the 160-bit seed value s, one can verify that the coefficient b was 
obtained from s via the cryptographic hash function SHA-1 as follows. 
Let / be the bit length of p, and define 

v =L(/- l)/160j 

w =/ - 160v- 1 

1. Compute h ;= SHA-1 (5). 

2. Let h 0 be the bit string obtained by taking the w rightmost bits of h. 

3. Let z be the integer whose binary expansion is given by the 160-bit string s. 

4. For / from 1 to v do 

4.1 Define the 160-bit string s, to be binary expansion of the integer 
(z + /)mod(2 160 ). 

4.2 Compute /z,:=SHA- lfo). 

5. Let h be the bit string obtained by the concatenation of h 0 , h u . . . , h v as follows: 

6. Let c be the integer whose binary expansion is given by the bit string h. 

7. Verify that b 2 c = -27 (mod p). 
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APPENDIX 6.6: GENERATION OF 
PSEUDO-RANDOM CURVES (BINARY CASE) 

Let: 

v = L(m- l)/5j 
w = m - Bv 

1. Choose an arbitrary 160-bit string s. 

2. Compute h := SHA-l(^) 

3. Let h 0 be the bit string obtained by taking the w rightmost bits of h. 

4. Let z be the integer whose binary expansion is given by the 160-bit string s. 

5. For i from 1 to v do: 

5.1 Define the 160-bit string s t to be binary expansion of the integer 
(z + 0mod(2 160 ). 

5.2 Compute /r, :=SHA-l(j f ). 

6. Let h be the bit string obtained by the concatenation of h 0 , h u . . . , h v as follows: 

h = h \\h x \\...\\h v . 

7. Let b be the element of GF(2 m ) which binary expansion is given by the bit string 
h. 

8. Choose an element a of GF(2 m ). 

9. Check that the elliptic curve E over GF{2 m ) given by y 2 + xy = 
x 3 + + b has suitable order. If not, go to Step 1 . 
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APPENDIX 6.7: VERIFICATION OF CURVE 
PSEUDO-RANDOMNESS (BINARY CASE) 

Given the 160-bit seed value s, one can verify that the coefficient b was 
obtained from s via the cryptographic hash function SHA-1 as follows. 
Define 

v = L(m- l)/160j 
w= m - 160v 

1. Compute h := SHA-1 (5) 

2. Let h 0 be the bit string obtained by taking the w rightmost bits of A. 

3. Let z be the integer whose binary expansion is given by the 160-bit string 
s. 

4. For i from 1 to v do 

4. 1 Define the 160-bit string s { to be binary expansion of the integer (z 
+ z)mod (2 160 ) 

4.2 Compute A,- :=SHA-l(s f ). ^ . 

5. Let h be the bit string obtained by the concatenation of h 0 , h l} . . . , h v as 

follows: 

h = h Q || h x ||...||Av 

6. Let c be the element of GF(l m ) which is represented by the bit string h. 

7. Verify that c = b. 



66 



APPENDIX 6.8: POLYNOMIAL BASIS TO NORMAL BASIS CONVERSION 

Suppose that a an element of the field GF(2 m ). Denote by p the bit string 
representing a with respect to a given polynomial basis. It is desired to compute n, 
the bit string representing a with respect to a given normal basis. This is done via 
the matrix computation 

p r = n 

Where T is an m-by-m matrix with entries in GF(2). The matrix T, which depends 
only on the bases, can be computed easily given its second-to-last row. The 
second-to-last row for each conversion is given in the table below. 



Degree 163: 



3 e!73bfaf 3a86434d 883a2918 a489ddbd 69fe84el 



Degree 233 : 



Obe 19b89595 28bbc490 
038f4bc4 da8bdfcl ca36bb05 853fd0ed 0ae200ce 



Degree 283: 



3347fl7 521fdabc 62ecl551 acfl56fb 
0bceb855 f!74d4cl 7807511c 9f745382 add53bc3 



Degree 409: 



0eb00f2 ea95fd6c 64024e7f 
0b68b81f 5ff8a467 acc2b4c3 b9372843 6265c7ff 
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a06d896c ae3a7e31 e295ec30 3eb9f769 de78bef5 

Degree 571: 

7940ffa ef9965 1 3 4d59dcbf 
e5bf239b e4fe4b41 05959c5d 4d942ffd 46ea35f3 
e3cdb0el 04a2aa01 cef30a3a 4947801 1 196bfb43 
c55091b6 1 174d7c0 8d0cdd61 3bf6748a bad972a4 

Given the second-to-last row r of T, the rest of the matrix is computed as 
follows. Let j3 be the element of GF(2 m ) whose representation with respect to the 
normal basis is r. Then the rows of T, from top to bottom, are the bit strings 
representing the elements 

with respect to the normal basis. (Note that "the element 1 is represented by the all-1 
bit string.) ^ 

Alternatively, the matrix is the inverse of the matrix described in Appendix 

6.9. 

More details of these computations can be found in Annex A. 7 of the IEEE 
PI 363 standard. 
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APPENDIX 6.9: NORMAL BASIS TO POLYNOMIAL BASIS CONVERSION 

Suppose that a an element of the field GF(2 m ). Denote by n the bit string 
representing a with respect to a given normal basis. It is desired to compute p, the 
bit string representing a with respect to a given polynomial basis. This is done via 
the matrix computation 

n r = p 

where Y is an m-by-m matrix with entries in GF(2). The matrix T, which depends 
only on the bases, can be computed easily given its top row. The top row for each 
conversion is given in the table below. 

Degree 163: 

7 15169c 10 9c612e39 0d347c74 8342bcd3 b02a0bef 

Degree 233 : <, 

149 9e398ac5 d79e3685 
59b35ca4 9bb7305d a6c0390b cf9e2300 253203c9 

Degree 283: 

31e0ed7 91c3282d c5624a72 0818049d 
053e8c7a b8663792 bcld792e ba9867fc 7b317a99 

Degree 409: 

0dfa06b e206aa97 b7a41fff 
b9b0c55f 8f048062 fbe838 lb 4248adf9 29 12ccc8 
e3f91a24 elcfb395 0532b988 971c2304 2e85708d 
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Desree 571: 



452186b bf5840a0 bcf8c9fO 
2a54efa0 4e813b43 c3d41496 06c4d27b 487bfl07 
393c8907 f79d9778 beb35ee8 7467d328 8274caeb 
da6ce05a eb4ca5cf 3c3044bd 4372232f 2cla27c4 

Given the top row r of T, the rest of the matrix is computed as follows. Let /3 
be the element of GF(2 m ) whose representation with respect to the polynomial 
basis is r. Then the rows of T, from top to bottom, are the bit strings representing 
the elements 

A/3 2 ,/3 22 p 2 "' 

with respect to the polynomial basis. 

Alternatively, the matrix is the inverse of the matrix described in Appendix 

6.8. 

More details of these computations can be found in Annex A.7 of the IEEE 
PI 363 standard. 
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FIPS 186-2, DIGITAL SIGNATURE STANDARD 
CHANGE NOTICE 1 

U.S. DEPARTMENT OF COMMERCE 

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 
Gaithersburg, MD 20899 

DATE OF CHANGE: 2001 October 5 

Federal Information Processing Standard (FIPS) 186-2, Digital Signature Standard, specifies the. 
Digital Signature Algorithm (DSA) that may be used in the generation and verification of digital 
signatures for sensitive, unclassified applications. FIPS 186-2 also allows the use of the -digital 
signature techniques specified in American National Standards Institute (ANSI) X9.31 (Digital 
Signatures Using Reversible Public Key Cryptography for the Financial Services Industry 
(rDSA)) and ANSI X9.62 (Public Key Cryptography for the Financial Services Industry: The 
Elliptic Curve Digital Signature Algorithm (ECDSA)). The standard also specifies a transition 
period for the use of existing (legacy) digital signature systems. Reversible public key 
algorithms, such as the RSA or Rabin- Williams algorithms, are often used in these legacy 
systems. 

FIPS 186-2 is used in conjunction with the hash function specified in FIPS 180-1, Secure Hash 
Standard (SHS), and includes specifications for the size of the prime modulus p, and algorithms 
for the generation of a user's private key, x,.and a user's per message secret number, k. 

This change notice provides changes for the continued use of DSA as specified in FIPS 186-2 
about the size of the prime modulus p, modifications for the random number generation 
techniques specified in Appendix 3 of FIPS 186-2, and provides instructions for the use of these 
techniques when used in contexts other than the generation of DSA keys. This change notice also 
provides guidance for the use of the reversible public key algorithms within legacy systems. 

Questions regarding this change notice may be directed to FIPS186@nist.gov or to Elaine Barker 
(ebarker@nist.gov, 301-975-2911). 

The Size of the Prime Modulus 

Section 4 of FIPS 186-2 specifies that the prime modulus p of DSA is defined for the range of 
prime integers 2 LA < p < 2 L , where 5 12 < L < 1024 and L is a multiple of 64. This change notice 
specifies that L should assume only the value 1024 for DSA as specified in FIPS 186-2, i.e., the 
prime modulus p should be defined in the range 2 1023 < p < 2 1024 . 

The RSA and Rabin-Williams algorithms used within legacy systems are defined with a modulus 
n and prime factors p and q of n. This change notice specifies that n should be at least 1024 bits 
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in length, and p and q should be approximately half the size of n in bits. 
Random Number Generation 

FIPS 186-2 includes algorithms for the generation of a user's private key, x, and a user's per 
message secret number, k. These values must be generated randomly or pseudorandomly and 
must have values between 0 and the 160-bit prime q (as specified in the standard). Techniques 
for generating x and k are provided in Appendix 3 of the standard. 

Recently, an unpublished attack on DSA3 was found that relies on the non-uniformity of the 
pseudorandom number generators (PRNGs) specified in Appendix 3 of the standard. The attack 
has a workfactor of 2 64 and requires 2 22 known signatures. This attack can be defended against by 
either limiting the number of signatures created using a specific key pair to no more than 2 
million signatures while using the PRNGs specified in FIPS 186-2, or by modifying the PRNGs. 

If the PRNGs currently defined in FIPS 186-2 are used, the user should be provided with clear 
guidance about the limitation to the number of signatures that should be created. 

Alternatively, the following modifications of the PRNGs may be used in lieu of those PRNGs 
specified in FIPS 186-2. These modifications reduce the non-uniformity of the PRNGs and do 
not affect interoperability. 

The two algorithms described below use a one-way function G(f,c), where Ms 160 bits, c is b bits 
and G(t,c) is 160 bits. Two methods for constructing G are defined in FIPS 186-2: using SHA-1 
as defined in FIPS 180-1, and using the Data Encryption Standard (DES) as defined in FIPS 46- 
3. If G is constructed using SHA-1, b is between 160 and 512 bits (160 < b < 512); if G is 
constructed using DES, b is equal to 160 bits. 

1. Revised Algorithm for Computing m values of x (Appendix 3.1 of FIPS 186-2) 
Let x be the signer's private key. The following may be used to generate m values of x: 
Step 1 . Choose a new, secret value for the seed-key, XKEY 
Step 2. In hexadecimal notation let 

/ = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0. 
This is the initial value for H Q || H } \\ Hi || #3 1| H A in the SHS [FIPS 180-1]. 



3 The attack was discovered by Dr. Daniel Bliechenbacher of Lucent Technologies, Bell Labs, Murray Hill, NJ. See 
a February 25, 2001 press article at http://www.lucent.com/press/Q201/01Q2Q5.bla.html . 
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Step 3. For j = 0 to m - 1 do 

3 . 1 XSEEDj = optional user input 

3.2 For i = 0 to 1 do 

i.XYAL =(XKEY + XSEEDj) mod 2 b 

b. w t - = G(f, ). 

c. AXZT = (1 + XKEY + W/ ) mod 2 6 . 

3.3 xy = (wo || wi) mod ^ 

2. Revised Algorithm for Precomputinq one or More k and r Values (Appendix 3.2 
of FIPS 186-2) 

This algorithm can be used to precompute k 9 k'\ and r for m messages at a time. Note that 
implementation of the DSA with precomputation may be covered by U.S. and foreign patents. 

Step 1. Choose a secret initial value for the seed-key, KKEY. 

Step 2. In hexadecimal notation let 

t = EFCDAB89 98BADCFE 10325476 C3D2E1F0 67452301. 

This is a cyclic shift of the initial value for H 0 || H x \\ H 2 \\ # 3 1| H A in the SHS. 

Step 3. For; = 0 tow - 1 do 

3.1 For/ = 0 to 1 do 

a. Wi = G(t y KKEY) 

b. KKEY = (I + KKEY + Wi) mod 2 b 

3.2 k= (w 0 || W]) mod q 

3.3 Compute kf l = k~ l mod q 

3 .4 Compute r, = (g k mod p) mod q 
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Step 4. Suppose M 0 ,...,M„.\ are the next m messages. F017 = 0 to m - 1 do 
aA&et h = SHA-1(M,). 

b. hex Sj = (kf\h + xrj)) mod q 

c. The signature for M } is (r,-, sj). 
Step 5. Let / = h 

Step 6. Go to step 3. 

Step 3 permits pre-computation of the quantities needed to sign the next m messages. Step 4 can 
begin whenever the first of these m messages is ready. The execution of step 4 can be suspended 
whenever the next of the m messages is not ready. As soon as steps 4 and 5 have completed, step 
3 can be executed, and the results saved until the first member of the next group of m messages is 
ready. 

In addition to space for KKEY , two arrays of length m are needed to store r 0 , ... r m .\ and £o"\ > Kn-\ 
1 when they are computed in step 3. Storage for s 0 , ... , 5„.i is only needed if the signatures for a 
group of messages are stored; otherwise Sj in step 4 can be replaced by s, and a single space 
allocated. 



General Purpose Random Number Generation 

Several of the FIPS require the use of an Approved (i.e., FlPS-approved or NIST recommended) 
random number generator (RNG). The RNG specified as algorithm 1 above or the algorithm 
specified in Appendix 3.1 of FIPS 186-2 may be used in addition to any other Approved RNG. 
However, when the RNG is used for the generation of random numbers other than for DSA keys, 
the "mod q" term should be omitted. This will result in the following changes to the 
specification: 

FIPS 186-2, Appendix 3.1, Step 3 c: 

Change " Xj = G(t, XVAL ) mod q" to "x y = G(f, XVAL )". 

Algorithm 1 of this change notice, Step 3, substep 3.2: 

Change " Xj = (w 0 || w x ) mod q" to " Xj = (w 0 || wi) M . 
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Foreword 



The Federal Information Processing Standards Publication Series of the National Institute of 
Standards and Technology (NIST) is the official series of publications relating to standards and 
guidelines adopted and promulgated under the provisions of Section 5131 of the Information 
Technology Management Reform Act of 1996 (Public Law 104-106), and the Computer Security 
Act of 1987 (Public Law 100-235). These mandates have given the Secretary of Commerce and 
NIST important responsibilities for improving the utilization and management of computer and 
related telecommunications systems in the Federal Government. The NIST, through its Information 
Technology Laboratory, provides leadership, technical guidance, and coordination of Government 
efforts in the development of standards and guidelines in these areas. 

Comments concerning Federal Information Processing Standards Publications are welcomed and 
should be addressed to the Director, Information Technology Laboratory, National Institute of 
Standards and Technology, 100 Bureau Dr. Stop 8900, Gaithersburg, MD 20899-8900. 

William Mehuron, Director' 1 
Information Technology Laboratory- 



Abstract 

This standard specifies a suite of algorithms which can be used to generate a digital signature. 
("Digital signatures are. used to detect unauthorized modifications to data and to authenticate the 
1 identity of the signatory. In addition, the recipient of signed data can use a digital signature in 
proving to a third party that the signature was in fact generated by the signatory. This is known as 
nonrepudiation since the signatory cannot, at a later time, repudiate the signature. 

Key words: ADP security, computer security, digital signatures, public-key cryptography, Federal 
Information Processing Standards. 
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Federal Information 
Processing Standards Publication 186-2 

2000 January 27 

Announcing the 

DIGITAL SIGNATURE STANDARD (DSS) 



Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National 
Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant 
to Section 5 1 3 1 of the Information Technology Management Reform Act of 1 996 (Public Law 1 04- 
106), and the Computer Security Act of 1987 (Public Law 100-235). 

Name of Standard: Digital Signature Standard (DSS). 

Category of Standard: Computer Security, Cryptography. 

Explanation: This Standard specifies algorithms appropriate for applications requiring a digital, 
rather than written, signature. A digital signature is represented 1 in a computer as a string of binary 
digits. A digital signature is computed using a set of rules and a set of parameters such that the 
identity of the signatory and integrity of the data can be verified. An algorithm provides the 
capability to generate and verify signatures. Signature generation makes use of a private key to 
generate a digital signature. Signature verification makes use of a public key which corresponds to, 
but is not the same as, the private key. Each user possesses a private and public key pair. Public 
keys are assumed to be known to the public in general. Private keys are never shared. Anyone can 
verify the signature of a user by employing that user's public key. Signature generation can be 
performed only by the possessor of the user's private key. 

A hash function is used in the signature generation process to obtain a condensed version of data, 
called a message digest (see Figure 1). The message digest is then input to the digital signature (ds) 
algorithm to generate the digital signature. The digital signature is sent to the intended verifier along 
with the signed data (often called the message). The verifier of the message and signature verifies 
the signature by using the sender's public key. The same hash function must also be used in the 
verification process. The hash function is specified in a separate standard, the Secure Hash Standard 
(SHS), FIPS 180-1. FIPS approved ds algorithms must be implemented with the SHS. Similar 
procedures may be used to generate and verify signatures for stored as well as transmitted data. 
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Approving Authority: Secretary of Commerce. 

Maintenance Agency: U.S. Department of Commerce, National Institute of Standards and 
Technology (NIST), Information Technology Laboratory (ITL). 

Applicability: This standard is applicable to all Federal departments and agencies for the protection 
of sensitive unclassified information that is not subject to section 2315 of Title 10, United States 
Code, or section 3502(2) of Title 44, United States Code. This standard shall be used in designing 
and implementing public-key based signature systems that Federal departments and agencies operate 
or which are operated for them under contract. Adoption and use of this standard is available to 
private and commercial organizations. 

Applications: A digital signature (ds) algorithm authenticates the integrity of the signed data and 
the identity of the signatory. A ds algorithm may also be used in proving to. a third party that data 
was actually signed by the generator of the signature. A ds algorithm is intended for use in electronic 
mail, electronic funds transfer, electronic data interchange, software distribution, data storage, and 
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other applications that require data integrity assurance and data origin authentication. The 
techniques specified in ANSI X9.31 and ANSI X9.62 may be used in addition to the Digital 
Signature Algorithm (DSA) specified herein. (NIST editorial note: either DSA, RSA [ANSI X9.31], 
or ECDSA [ANSI X9.62] may be used; all three do not have to be implemented.) 

Implementations: A ds algorithm may be implemented in software firmware, hardware or any 
combination thereof. NIST has developed a validation program to test implementations for 
conformance to DSA. Currently, conformance tests for ANSI X9.3 1 and ANSI X9.62 have not been 
developed. These tests will be developed and made available in the future. Information about the 
planned validation program can be obtained from the National Institute of Standards and 
Technology, Information Technology Laboratory, Attn: DSS Validation, 100 Bureau Drive Stop 
8930, Gaithersburg, MD 20899-8930. 

Agencies axe advised that separate keys should be used for signature and confidentiality purposes 
when using the X9.3 1 standard. This is because the RSA algorithm can be used for both data 
encryption and digital signature purposes. 

Export Control: Certain cryptographic devices and technical data regarding them are subject to 
Federal export controls. Applicable Federal government export controls are specified in Title 15, 
Code of Federal Regulations (CFR) Part 740.17; Title 15, CFR Part 742; and Title 1 5, CFR Part 774, 
Category 5, Part 2. 

Patents: The algorithms in this standard may be-covered by U.S. or foreign patents. 

Implementation Schedule: This standard becomes effective July 27, 2000. A transition period from 
July 27, 2000 until July 27, 2001 is provided to enable all Agencies to develop plans for the 
acquisition of equipment which implements the digital signature techniques adopted by FIPS 186-2. 

During the transition period, agencies may continue to use their existing digital signature systems 
and to acquire additional equipment that may be needed to interoperate with these legacy digital 
signarure systems. Agencies without legacy digital signature systems should plan for the acquisition 
and use of equipment implementing the digital signature techniques that are adopted by FIPS 186-2. 

After the transition period, only equipment that implements FIPS 186-2 endorsed techniques should 
be acquired. 

Specifications: Federal Information Processing Standard (FIPS) 186-2 Digital Signature Standard 
(affixed). Also see an important chance notice at the end of this document. 

Cross Index: 

a. FIPS PUB 46-3, Data Encryption Standard. 

b. FIPS PUB 73, Guidelines for Security of Computer Applications. 
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c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. 

d. FIPS PUB 1 7 1 , Key Management Using ANSI X9. 17. 

e. FIPS PUB 180-1, Secure Hash Standard. 

f. ANSI X9.31-1998, Digital Signatures Using Reversible Public Key Cryptography for the 
Financial Services Industry (rDSA). 

g. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic 
Curve Digital Signature Algorithm (ECDSA). 

Qualifications: The security of a digital signature system is dependent on maintaining the secrecy 
of users' private keys. Users must therefore guard against the unauthorized acquisition of their 
private keys. While it is the intent of this standard to specif/ general security requirements for 
generating digital signatures, conformance to this standard does not assure that a particular 
implementation is secure. The responsible authority in each agency or department shall assure that 
an overall implementation provides an acceptable level of security. This standard will be reviewed 
every five years in order to assess its adequacy. 

Waiver Procedure: Under certain exceptional circumstances, the heads of Federal agencies, or their 
delegates, may approve waivers to Federal Information Processing Standards (FIPS). The head of 
such agency may redelegate such authority only to a senior official designated pursuant to section 
3506(b) of Title 44, United States Code. Waiver shall be granted only when: 

a. Compliance with a standard would adversely affect the accomplishment of the mission of an 
operator of a Federal computer system; or 

b. Cause a major adverse financial impact on the operator which is not offset by Government wide 
savings. 

Agency heads may act upon a written waiver request containing the information detailed above. 
Agency heads may also act without a written waiver request when they determine that conditions for 
meeting the standard cannot be met. Agency heads may approve waivers only by a written decision 
which explains the basis on which the agency head made the required finding(s). A copy of each 
such decision, with procurement sensitive or classified portions clearly identified, shall be sent to: 
National Institute of Standards and Technology; ATTN: FIP S Waiver Decisions, 100 Bureau Drive 
Stop 8970, Gaitbersburg, MD 20899-8970. 

In addition, notice of each waiver granted and each delegation of authority to approve waivers shall 
be sent prompdy to the Committee on Government Operations of the House of Representatives and 
the Committee on Governmental Affairs of the Senate and shall be published promptly in the Federal 
Register. 
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When the determination on a waiver applies to the procurement of equipment and/or services, a 
notice of the waiver determination must be published in the Commerce Business Daily as a part of 
the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that 
notice is published, by amendment to such notice. 

A copy of the waiver, any supporting documents, the document approving the waiver and any 
supporting and accompanying documents, with such deletions as the agency is authorized and 
decides to make under 5 U.S.C. Sec. 552(b), shall be part of the procurement documentation and 
retained by the agency. 

Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National 
Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When 
ordering, refer to Federal Information Processing Standards Publication L86-2 (FIPSPUB1 86-2), and 
identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS 
in current catalogs and other issuances. Payment may be made by check, money order, deposit 
account or charged to a credit card accepted by NTIS. 
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Specifications for the 
DIGITAL SIGNATURE STANDARD (DSS) 
1. INTRODUCTION 

This publication prescribes three algorithms suitable for digital signature (ds) generation and 
verification. The first algorithm, the Digital Signature Algorithm (DSA), is described in sections 
4 - 6 and appendices 1 - 5. The second algorithm, the RSA ds algorithm, is discussed in section 7 
and the third algorithm, the ECDSA algorithm, is discussed in section 8 and recommended elliptic 
curves in appendix 6. An important change notice has been appended to this document. 

2. GENERAL 

fwhen a message is received, the recipient may desire to verify that the message has not been altered 
I in transit. Furthermore, the recipient may wish to be certain of the originator's identity. Both of 
these services can be provided by a ds algorithm. A digital signature is an electronic analogue of a 
written signature in that the digital signature can be used in proving to the recipient or a third party 
that the message was, in fact, signed by the originator. Digital signatures may also be generated for 
stored data and programs so that the integrity of the data and programs may be verified at any later 
time. 

This publication prescribes two algorithms suitable for digital signature generation and verification. 



3. USE OF A DIGITAL SIGNATURE (ds) ALGORITHM 

'a ds algorithm is used by a signatory to generate a digital signature on data and by a verifier to 
verify me authenticity of the signature. Each signatory has a public and private key. The private key 
is used in the signature generation process and the public key is used in the signature verification 
process For both signature generation and verification, the data which is referred to as a message, 
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M, is reduced by means of the Secure Hash Algorithm (SHA-1) specified in FTPS 180-1. An 
adversary, who does not know the private key of the signatory, cannot generate the correct signature 
of the signatory. In other words, signatures cannot be forged. However, by using the signatory's 
public key, anyone can verify a correctly signed message. A means of associating public and private 
key pairs ro the corresponding users is required. That is, there must be a binding of a user's identity 
and the user's public key. This binding may be certified by a mutually trusted party. For example, 
a certifying authority could sign credentials containing a user's public key and identity to form a 
certificate. Systems for certifying credentials and distributing certificates are beyond the scope of 
this standard. N1ST intends to publish separate documents) on certifying credentials and distributing 
certificates. 



4. DSA PARAMETERS 

The DSA makes use of the following parameters: 

1 . p = a prime modulus, where 2 M < p < 2 L for 5 1 2 < L < 1 024 and L a multiple of 64 

2. q = a prime divisor of p - 1, where 2 159 < q < 2 160 

3. g = h^ 1Vs mod p, where h is any integer with 1 < h < p - 1 such that h^ 1 ^ mod p > 1 
(g has order q mod p) 

4. x = a randomly or pseudorandomly generated integer with 0 < x < q 

5. y = g*modp 

6. k = a randomly or pseudorandomly generated integer with 0 < k < q 

The integers p, q, and g can be public and can be common to a group of users. A user's private and 
public keys are x and y, respectively. They are normally fixed for a period of time. Parameters x 
and k are used for signature generation only, and must be kept secret. Parameter k must be 
regenerated for each signature. 

Parameters p and q shall be generated as specified in Appendix 2, or using other FIPS approved 
security methods. Parameters x and k shall be generated as specified in Appendix 3, or using other 
FIPS approved security methods. 

5. DSA SIGNATURE GENERATION 

The signature of a message M is the pair of numbers r and s computed according to the equations 
below: 
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